- This topic has 1 reply, 2 voices, and was last updated 2 years, 4 months ago by
.
-
Posts
-
Hello,
our company is using VisualGDB to develop embedded Software for Microchip SAM devices. We are using the Atmel ICE ISP for this. VisualGDBÂ is working flawless with the SAME70, however debugging is almost impossible on SAM4S. It’s not a hardware issue; everything is working fine in Atmel/Microchip Studio.
Here is what usually happens:
- the chip erase takes unusually long, but works in the end
- after that, an exception is triggered at the reset handler line “_libc_init_array()”, so before the main(). The exception is: “Received a SIGTRAP: Trace/breakpoint trap”. The execution can not be continued.
Sometimes, a hard erase is needed after this. Sometimes, the execution progresses and it runs to the first breakpoint, but never hits another one after this (although the code is working in Atmel/Microchip Studio).
OpenOCD-Log: target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0080004c msp: 0x20000800 Info : Erasing FLASH: 0x00400000-0x00482000... Info : sam4 does not auto-erase while programming (Erasing relevant sectors) Info : sam4 First: 0x00000000 Last: 0x00000040 Info : Erasing sector: 0x00000000 Info : Erasing sector: 0x00000001 Info : Erasing sector: 0x00000002 Info : Erasing sector: 0x00000003 Info : Erasing sector: 0x00000004 Info : Erasing sector: 0x00000005 Info : Erasing sector: 0x00000006 Info : Erasing sector: 0x00000007 Info : Erasing sector: 0x00000008 Info : Erasing sector: 0x00000009 Info : Erasing sector: 0x0000000a Info : Erasing sector: 0x0000000b Info : Erasing sector: 0x0000000c Info : Erasing sector: 0x0000000d Info : Erasing sector: 0x0000000e Info : Erasing sector: 0x0000000f Info : Erasing sector: 0x00000010 Info : Erasing sector: 0x00000011 Info : Erasing sector: 0x00000012 Info : Erasing sector: 0x00000013 Info : Erasing sector: 0x00000014 Info : Erasing sector: 0x00000015 Info : Erasing sector: 0x00000016 Info : Erasing sector: 0x00000017 Info : Erasing sector: 0x00000018 Info : Erasing sector: 0x00000019 Info : Erasing sector: 0x0000001a Info : Erasing sector: 0x0000001b Info : Erasing sector: 0x0000001c Info : Erasing sector: 0x0000001d Info : Erasing sector: 0x0000001e Info : Erasing sector: 0x0000001f Info : Erasing sector: 0x00000020 Info : Erasing sector: 0x00000021 Info : Erasing sector: 0x00000022 Info : Erasing sector: 0x00000023 Info : Erasing sector: 0x00000024 Info : Erasing sector: 0x00000025 Info : Erasing sector: 0x00000026 Info : Erasing sector: 0x00000027 Info : Erasing sector: 0x00000028 Info : Erasing sector: 0x00000029 Info : Erasing sector: 0x0000002a Info : Erasing sector: 0x0000002b Info : Erasing sector: 0x0000002c Info : Erasing sector: 0x0000002d Info : Erasing sector: 0x0000002e Info : Erasing sector: 0x0000002f Info : Erasing sector: 0x00000030 Info : Erasing sector: 0x00000031 Info : Erasing sector: 0x00000032 Info : Erasing sector: 0x00000033 Info : Erasing sector: 0x00000034 Info : Erasing sector: 0x00000035 Info : Erasing sector: 0x00000036 Info : Erasing sector: 0x00000037 Info : Erasing sector: 0x00000038 Info : Erasing sector: 0x00000039 Info : Erasing sector: 0x0000003a Info : Erasing sector: 0x0000003b Info : Erasing sector: 0x0000003c Info : Erasing sector: 0x0000003d Info : Erasing sector: 0x0000003e Info : Erasing sector: 0x0000003f Info : Erasing sector: 0x00000040 Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (3248 ms). Workaround: increase "set remotetimeout" in GDB Info : Programming FLASH (2 sections, 525720 bytes)... Info : Programming FLASH section 1/2 (204 bytes) at 0x00400000... Info : Padding image section 0 at 0x004000cc with 4 bytes Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (24901 ms). Workaround: increase "set remotetimeout" in GDB target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0080004c msp: 0x20000800
Any idea what could help?
Best regards,
Nikolas Becker
Hi,
This looks like an issue in OpenOCD rather than something VisualGDB-specific. You can try building OpenOCD from sources by following this tutorial, and then step through it to understand what is going on.
Another option would be to switch to Segger J-Link. It comes with its own fully supported replacement to OpenOCD, that generally works better for many devices.
If the Atmel IDE works well, you can also try using Process Monitor to to see if uses gdb and whether it launches its own gdb stub similar to OpenOCD. If both are true, and you can run the same stub manually (and connect GDB to it), you can configure VisualGDB to launch it as well by selecting the “Custom GDB stub” mode in VisualGDB Project Properties -> Debug Settings. Note that the last option is something to do at your own risk, as it involves running undocumented Atmel tools.
- You must be logged in to reply to this topic.