My name is Alex, I’m working with Hackmodford (Brandon) on the Arduino Due with the Atmel ICE debugger. Just want to let you know Brandon hit the “max # of replies for a new user” so he’s unable to reply at the moment. He is able to append to his old replies though, not sure if you saw it, but Brandon mentioned that he tried flashing the ATmel ICE manually but that did not seem to change the result. Do you have any other suggestions? Thank you for your help. We really want this debugger to work.
Hm. Let’s first patch the corrected upload method via an extra script to make that more robust, maybe the pio debug command can then also upload the (right) firmware?
Then let’s try the same openocd target for debugging, maybe things change. Still, the build_flag stuff should be kept in there to ensure a debug build for now. Add to the platformio.ini (adapted from docs):
Reading symbols from /Users/hackmodford/Code/PlatformIO/FSMotionController/.pio/build/due/firmware.elf...
done.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = custom
PlatformIO: Initializing remote target...
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-15:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
at91sam3X8E
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : tcl server disabled
Info : telnet server disabled
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: FW Version = 01.27.0082
Info : CMSIS-DAP: Serial# = J41800107410
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : SWD DPIDR 0x2ba01477
Info : at91sam3X8E.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x00083ff2 msp: 0x20087f40
SPIClass::transfer (this=this@entry=0x20070de8 <SPI>, _pin=_pin@entry=78 'N', _buf=_buf@entry=0x20087f64, _count=1, _count@entry=3, _mode=_mode@entry=SPI_LAST) at /Users/hackmodford/.platformio/packages/framework-arduinosam/libraries/__cores__/sam/SPI/src/SPI.cpp:260
260 while ((spi->SPI_SR & SPI_SR_RDRF) == 0)
Temporary breakpoint 1 at 0x88256: file /Users/hackmodford/.platformio/packages/framework-arduinosam/cores/sam/main.cpp, line 45.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000892b0 msp: 0x20088000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000892b0 msp: 0x20088000
Info : sam3 auto-erases while programming (request ignored)
Loading section .text, size 0xe868 lma 0x80000
Loading section .ARM.exidx, size 0x8 lma 0x8e868
Loading section .relocate, size 0xa70 lma 0x8e870
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (4293). Workaround: increase "set remotetimeout" in GDB
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000892b0 msp: 0x20088000
Start address 0x892b0, load size 62176
Transfer rate: 13 KB/sec, 10362 bytes/write.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000892b0 msp: 0x20088000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000892b0 msp: 0x20088000
PlatformIO: Initialization completed
PlatformIO: Resume the execution to `debug_init_break = tbreak main`
PlatformIO: More configuration options -> http://bit.ly/pio-debug
Note: automatically using hardware breakpoints for read-only addresses.
Error: Can not find free FPB Comparator!
Error: can't add breakpoint: resource not available
Error: Can not find free FPB Comparator!
Error: can't add breakpoint: resource not available
Warning:
Cannot insert hardware breakpoint 2.
Cannot insert hardware breakpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
Seems like the debugger is kinda overloaded with the breakpoint requests (no flash patch blocks / breakpoints free)? Can you try to remove all breakpoints, then start debugging, pause execution, place a breakpoint at loop(), then ‘continue’ and see if the breakpoint is hit? The logs for that would also be interesting.
Can you also try to again remove all breakpoints, add the line
debug_init_break = tbreak loop
to the platformio.ini (ref), then start debugging and see if it hits the breakpoint?
Ok, so I had the same problem, and solved it exactly like you did. Thanks to maxgerhardt. Now I’m wondering if that’s a desired behaviour ? or does it get fixed in the future ?
If you tell me that’s the desired behaviour I’d be fine with that too, because it’s just a question of configuring openocd the right way. But still the question remains in my head.
Nonetheless thanks maxgerhardt for helping out noobs
Any tips?
What I tried: ${USERPROFILE}/.platformio/packages/tool-openocd/bin/openocd $USERPROFILE$/.platformio/packages/tool-openocd/bin/openocd Users/firstname^ lastname/.platformio/packages/tool-openocd/bin/openocd Users/"firstname lastname"/.platformio/packages/tool-openocd/bin/openocd
Thank you very much for your post. You did not only help Hackmodford but also myself. I have opened a new topic that would have fitted into here, but I have linked to your solution.
I have previously worked with a combination of notepad++ for editing, Arduino IDE for compiling, and Atmel Studio 7 for uploading .elf/.hex files. But I have obviously missed an integrated IDE that allows debugging with breakpoints. I have tried many times (and failed) to open Arduino Due projects directly in Atmel Studio, as not all of the paths were set correctly. So being able to use an integrated IDE is great!
However, I feel on really thin ice here, as I am not sure what exactly you did with these switch settings that fixed the problem, and I would be completely helpless if I found myself in a similar situation in the future. I hope that not all the debug/upload setups are that cumbersome for every single processor…
