SAM4S + Atmel ICE: Debugger not working

Sysprogs forums Forums VisualGDB SAM4S + Atmel ICE: Debugger not working

This topic contains 1 reply, has 2 voices, and was last updated by  support 2 months, 2 weeks ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #32815



    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).

    Any idea what could help?

    Best regards,

    Nikolas Becker

    • This topic was modified 2 months, 2 weeks ago by  support. Reason: formatting



    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.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.