Description
A typical debugging session with openocd + gdb looks like
arm-none-eabi-gdb filename.ino.elf eval-command "target remote | \"openocd" -c \"gdb_port pipe\" --search \"...openocd/scripts/\" --file \".../openocd_scripts/arduino_zero.cfg\""
load
monitor reset halt
monitor reset init
continue
Unfortunately, this ends up with the bootloader being wiped out and the registers containing dummy data.
If we relocate the sketch to flash position 0x4000 instead than using 0x2000, everything works perfectly.
From http://forum.arduino.cc/index.php?topic=330338.msg2590441#msg2590441 it appears that .org boards are immune to this problem.
Looking at the M0 pro linker script, the sketch starts at 0x4000 and the board is debuggable.
The flash organization is
#0 : at91samd at 0x00000000, size 0x00040000, buswidth 1, chipwidth 1
# 0: 0x00000000 (0x4000 16kB) not protected
# 1: 0x00004000 (0x4000 16kB) not protected
# 2: 0x00008000 (0x4000 16kB) not protected
# 3: 0x0000c000 (0x4000 16kB) not protected
# 4: 0x00010000 (0x4000 16kB) not protected
# 5: 0x00014000 (0x4000 16kB) not protected
Should we patch openocd maybe? Or patching the bootloader relocation could be a better long time strategy (ld scripts are in the core, so I'd avoid this second option)
arduino/OpenOCD#2 could be a solution, but it is untested on smaller SAMD... Should we open a PR to mainline openocd and see what people say?