|
Posted on:
|
Trying to debug LPC1768 project (with FreeRTOS) on hardware with J-Link GDB Server I encountered problem: debugger receives SIGTRAP signal on instruction SVC 0 (in function vPortStartFirstTask). As if breakpoint catches. I can't understand why. I'm trying resume but it triggers again. On single step it hangs and j-link shows a lot of these events (target halted, started CPU, target halted, etc.). Moreover, I tried standard example CORTEX_LPC1768_GCC_RedSuite from FreeRTOS. The same. But IAR projects work fine. I'm using Yagarto toolchain. (Tried both old arm-elf and latest arm-eabi versions). gdb commands I specified in Eclipse debug configuration: monitor endian little monitor flash device = LPC1768 monitor flash download = 1 monitor flash breakpoints = 1 monitor speed 1000 monitor reg r13 = (0x00000000) monitor reg pc = (0x00000004) Also I checked Reset and Delay and Halt options. Set breakpoint at: main and Resume also set and works fine (Program stopped at main, then I resume and it stopped on SVC 0) I worked with ARM7TDMI earlier and didn't experienced such problems.
|
Posted on:
|
I figured out what was wrong. Target didn't resetted. "Reset and Delay" and "Halt" options have no effect actually. It's a bug/feature in "C/C++ GDB Hardware Debugging" (version 7.0.0.201009241320) feature of Eclipse CDT. You have to specify "monitor reset 0" command manually. It's a pity because I could observe it easy as all being watched closelly in gdb server messages window and didn't noticed that "Resetting target" message doesn't appears anywhere :)
|
Posted on:
|
I had this same problem when moving from the integrated st-link debugger (on my STM32 G-Eval board) to using the J-Link cable Stuck at "SVC 0" I had the debugger configuration check boxes for "halt" and "reset and delay" checked and also had "monitor reset halt" in the initialzation box. But I changed it to "monitor reset 0" and now it comes out of reset correctly.
Watch this topic
Disable multi-page view