This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Spurious GDB traps using OpenRISC and eCos
- From: "Robert Cragie" <rcc at jennic dot com>
- To: "ECOS" <ecos-discuss at ecos dot sourceware dot org>, "OpenRISC" <openrisc at opencores dot org>
- Date: Tue, 30 Mar 2004 17:49:12 +0100
- Subject: [ECOS] Spurious GDB traps using OpenRISC and eCos
I am trying to build a ROM 'monitor' which contains only GDB debugging stubs
and can debug code which is downloaded into RAM. On startup, the code to be
debugged is bootstrapped from a serial Flash device into RAM and then the
breakpoint() function (which I have copied) is called. The idea is that all
the exception handlers remain in ROM and only interrupt handlers can be
claimed by RAM. But at the moment I'm not using interrupts at all apart from
the ctrl-c interrupt for GDB interruption, which I want to be handled by the
ROM code.
The problem is is that I cannot single step or continue from this point - it
just seems to keep coming bask to the same address - here is the output from
GDB.
Sending packet: $Hc-1#09...Ack
Packet received:
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $Hg0#df...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received:
00000000f0017348f001734c0000800700000700f001066c000000000000000000000002f000
017c0000000000000001f001057000000000f000f7f000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000f000003400008007
__breakinst () at Main/main.c:138
138 HAL_BREAKPOINT(_breakinst);
(gdb) stepi
Sending packet: $Hc0#db...Ack
Packet received:
Sending packet: $s#73...Ack
Packet received: T0540:f0000034;01:f0017348;
Sending packet: $g#67...Ack
Packet received:
00000000f0017348f001734c0000800700000700f001066c000000000000000000000002f000
017c0000000000000001f001057000000000f000f7f000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000f000003400008007
138 HAL_BREAKPOINT(_breakinst);
(gdb) stepi
Sending packet: $s#73...Ack
Packet received: T0540:f0000034;01:f0017348;
Sending packet: $g#67...Ack
Packet received:
00000000f0017348f001734c0000800700000700f001066c000000000000000000000002f000
017c0000000000000001f001057000000000f000f7f000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000f000003400008007
138 HAL_BREAKPOINT(_breakinst);
(gdb)
I cannot figure out why it is doing this - the 'T0540:f0000034;01:f0017348;'
packets look suspicious as if it is continually trapping, but why would it
do this? I have had it working fine before where all the code was linked
together at the same time. I am wondering if there is something I am missing
in the attempt to have RAM and ROM code coexisting.
Any clues as to what might be happening would be much appreciated. I am
using a customised version of the OpenRISC version of eCos which is on the
OpenCores website.
Robert Cragie, Design Engineer
Direct: +44 (0) 114 281 4512
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
http://www.jennic.com Tel: +44 (0) 114 281 2655 Confidential
_______________________________________________________________
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss