Hi,
I’m using the Ethernut3 board as a base for developing our application.
Recently I got Eclipse Europa with Yagarto toolchain running for
compiling and basic debugging.
I can load my application into RAM with gdb and it halts
at main(). I can step one line and set a breakpoint in main so it stops there.
Once the program runs I can halt it, but the program has crashed.
This is where I need help.
Something with interrupts, stack, vectors???
The program is a multitasking application based on Nut/OS.
I use OOCD R141 on WinXP with ARM-USB-OCD.
Any advice welcome!
Joerg
Hi,
I’ve had some success in debugging my ethernut3 board.
I forgot that I’ve activated the watchdog, so every time I
stopped the program I got a hard reset. :oops:
Now, everything works fine except breakpoints.
I can set breakpoints in the main() but not later in the threads.
The program halts but gdb does not seem to get response
from oocd.
I tried hardware and software breakpoints.
GDB:
Thread [0] (Suspended: Breakpoint hit.) <Stack is not available: Target is not responding (timed out).>
OOCD:
Error: gdb_server.c:101 gdb_get_char(): read: 10054
Any hints?
BTW: How does gdb know if to use hardware or software breakpoints?
(break, hbreak)
Greets,
Joerg
Hello Joerg,
could you send me a complete log (run with -d -l )?
By default, the OpenOCD disables software breakpoints on ARM7 targets, and sets the breakpoint type as requested by GDB.
You can tell the OpenOCD to always issue hardware breakpoints using the “arm7_9 force_hw_bktps enable” command.
If you want to use software breakpoints you need to enable them first: “arm7_9 sw_bkpts enable”. They’re off by default, because they take up one of only two hardware breakpoint units.
Regards,
Dominic
Hi Dominic,
Dominic:
could you send me a complete log (run with -d -l )?
You can tell the OpenOCD to always issue hardware breakpoints using the “arm7_9 force_hw_bktps enable” command.
If you want to use software breakpoints you need to enable them first: “arm7_9 sw_bkpts enable”
Dominic
Thank you, I will try to send you some more infos.
Because I use debugging in RAM there are a lot of ‘byte written’ messages in the beginning.
Yes,I used these commands to toggle between hard- and software breakpoints.
I used the soft ones for RAM debugging first.
I tried the hard ones only because the others didn’t work correctly.
I only wondered if GDB needs to know something about soft- or hardware
breakpoints.
Seems like he knows about the difference because he has the hbreak commands.
But I think this is done be OOCD internally?
Regards,
Joerg
The GDB remote protocol allows for both soft and hard breakpoints, but GDB usually doesn’t know if a specific location is in ROM or in RAM, so it usually just requests software breakpoints. You can manually specify the use of hardware breakpoints with the hbreak command. I’m not sure if the support for flash memory found in recent GDB versions changes this behaviour (in theory it could).
Regards,
Dominic
Hi Dominic,
did you take a look in the logging files I sent you?
I think you wouldn’t find there any hints, anyway. 
I tried gdb from command line at least, and everything works fine!
From time to time I get an:
Error: gdb_server.c:101 gdb_get_char(): read: 10054
But I think this is just an JTAG transmission error?
So for me it’s a problem Eclipse, again, still.
Seems like the mi interface, whatever it is, isn’t
maintained well by the GDB guys?
Maybe the Zylin plugin is still better than builtin Europa.
Will keep on looking for a nice IDE where debugging works!
There is some remote debugging support ongoing for CodeBlocks.
With a
set remote hardware-breakpoint-limit 2
you should prevent yourself from requesting more breakpoints
than you have when debugging in FLASH.
Regards,
Joerg