PlatformIO Community

Unable to attach debugger to Arduino Due


#1

I’m having a problem getting the debugger to start. I get this error when I try to start a debugging session: Error erasing flash with vFlashErase packet.

I’m using a Mac with a Black Magic Probe connected to an Arduino Due. I’ve tried both VSCode and Atom, but both have the same error. I also tried connecting using iTerm but get same error with vFlashErase.

I have had success connecting to a 1bitsy and Arduino M0 using iTerm, Atom and (sometimes) VSCode so I know the BMP works, and my connections are ok.

I’m not sure where to start looking for the problem. I haven’t been able to find anything relevant while searching for the vFlashErase error.

My ini file looks like this:

platform = atmelsam
board = mzeroUSB
; board = dueUSB
framework = arduino
debug_tool = blackmagic
upload_protocol = blackmagic
debug_port = /dev/cu.usbmodem7AB57B81

Any help or suggestions are welcome. Thanks.


#2

Do you use correct board?


#3

Double checked. Yes, correct board used.


#4

So, after playing around with it some more I can debug using iTerm with the BMP connected to the Due.

Here’s the commands:

arm-none-eabi-gdb .pioenvs/blink/firmware.elf
GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .pioenvs/blink/firmware.elf...done.
(gdb) target extended-remote /dev/cu.usbmodem7AB57B81
Remote debugging using /dev/cu.usbmodem7AB57B81
(gdb) monitor swdp_scan
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Atmel SAM3X
(gdb) attach 1
Attaching to program: /Users/david/Documents/PlatformIO/Projects/test arduino debugger/.pioenvs/blink/firmware.elf, Remote target
0x00080840 in _sbrk (incr=<optimized out>)
    at /Users/david/.platformio/packages/framework-arduinosam/cores/sam/syscalls_sam3.c:78
78	}
(gdb) b main.cpp:13
Breakpoint 1 at 0x8014a: file src/main.cpp, line 13.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, loop () at src/main.cpp:13
13	    digitalWrite(LED_BUILTIN, HIGH);
(gdb)

But, in VSCode when I click Debug the debug console shows this, and the session doesn’t start.

Reading symbols from /Users/david/Documents/PlatformIO/Projects/test arduino debugger/.pioenvs/blink/firmware.elf...
done.
PlatformIO Unified Debugger > http://bit.ly/pio-debug
PlatformIO: Initializing remote target...
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Atmel SAM3X
Temporary breakpoint 1 at 0x80186: file src/main.cpp, line 5.
.pioinit:23: Error in sourced command file:
Error erasing flash with vFlashErase packet

Does this information provide any clues to the problem?


#5

Could you add to platformio.ini these lines?

[env:myenv]
debug_load_cmd = 
debug_load_mode = manual

Does it work now?


#6

That did help to connect to the target, and I can step through the code and set breakpoints. Thanks!!

The next issue I’m facing is variables are not updating. Setting their value in the IDE doesn’t give any error, but doesn’t seem to be set on the target.

My program has a variable that is used to set the delay in a blink led example. When I try to set the variable value from the IDE, or from the debug console there’s no errors given, and the value seems to update in the debugger, but not on the target. It feels like the variable value is cached and updated locally, but not pushed to the target. Is there a command I need to use to force the variable value to be loaded to the target?

Here’s my program:

#include <Arduino.h>

void setup() {
    // put your setup code here, to run once:
    pinMode(LED_BUILTIN, OUTPUT);
}

int i = 0;

void loop() {
    // put your main code here, to run repeatedly:
    digitalWrite(LED_BUILTIN, HIGH);
    delay(i);
    digitalWrite(LED_BUILTIN, LOW);
    delay(i);
    if ((i++ % 10) == 0) {
        i += 50;
    }
}

Here’s my platformio.ini file:

[env:blink]
platform = atmelsam
board = dueUSB
framework = arduino
upload_port = /dev/cu.usbmodem31
monitor_port = /dev/cu.usbmodem31
debug_tool = blackmagic
debug_port = /dev/cu.usbmodem7AB57B81
debug_load_cmd =
debug_load_mode = manual
debug_init_cmds =
  target extended-remote $DEBUG_PORT
  monitor swdp_scan
  attach 1
  break main.cpp:setup

I don’t know if my problem is that I’m not issuing the load command to GDB. If I do then I get the vFlashErase error.


Debugging Arduino Due with Black Magic Probe and VScode/W10
#7

Maybe you need extra debug symbols? add build_flags = -O0 -ggdb -g3 and build_unflags = -Os to your platformio.ini to build the .elf file with debug symbols and no optimizations.


#8

Maxgerhardt, thanks! That definitely worked for my Arduino M0, but the Arduino Due still doesn’t set variables on the target.

Just having the build_flags = -O0 -ggdb -g3 allowed me to compile.

I had to remove build_unflags = -Os because the linker gave this error:

.pioenvs/blink/libFrameworkArduino.a(Uart.cpp.o): In function `HardwareSerial::HardwareSerial()':
/Users/david/.platformio/packages/framework-arduinosam/cores/samd/HardwareSerial.h:67: undefined reference to `vtable for HardwareSerial'
collect2: error: ld returned 1 exit status
*** [.pioenvs/blink/firmware.elf] Error 1

I’m not sure why HardwareSerial is an issue since I’m not using a serial port.

At this point the Arduino M0 I would say is good to go. While the Due can connect and step through code it still can’t update variables. I’m starting to wonder if there’s something else about the Due JTAG port that we’re missing.


#9

Now, please remove all these lines and use just the one instead. debug_load_cmd = preload. Need to flash board with firmware which contains debug symbols.


#10

OK, I tried this. The debugger can’t connect to the target with these changes.

To be able to connect I still needed all the debug_init_cmds and debug_load_cmd =. So my .ini file has this:

debug_load_cmd =
debug_init_cmds =
  target extended-remote $DEBUG_PORT
  monitor swdp_scan
  attach 1
  break main.cpp:setup

With this I can connect to the target (Due). I can single step and set breakpoints. I still can’t manipulate variables in VSCode. The watch window in the GUI doesn’t update, and the debug console doesn’t read/write values although other commands (n, s, f, c, etc,) do work.

If I use Atom with the same .ini file I can connect, single step, breakpoint, and manipulate variables in the GUI watch window. Basically, everything seems to work.


#11

My dad and I have a very similar setup as @ptcryan; Arduino Due and Black Magic Probe (on Windows). We’ve tried both VS Code and Atom without success, getting errors like the Error erasing flash with vFlashErase packet, or errors relating to invalid commands for target, etc. It seems like we’ve tried everything, but surely someone has reached a working configuration?

Building and uploading normally work fine, it’s when you have to pass through the debugger that things get messy quick.

Our most recent version looks like the below config. We have a very simple blink source code like above.

[env:due]
platform = atmelsam
board = due
debug_tool = blackmagic
framework = arduino
monitor_speed = 38400

debug_port = COM9
upload_protocol = blackmagic

debug_init_cmds =
  target extended-remote $DEBUG_PORT
  monitor swdp_scan
  attach 1

We’re anxious to figure this out. Why should we pay a monthly fee if we can barely get PlatformIO off the ground?


#12

After much toil we finally found a working configuration. We avoided uploading via the debugger altogether, and instead used another COM port with the sam-ba protocol instead. Whatever GDB commands PlatformIO thinks are right are no good either.

[env:due]
platform = atmelsam
board = due
board_build.mcu = at91sam3x8e
board_build.f_cpu = 84000000L
framework = arduino
; If any of your ports are 10 or over, use this format: \\.\COM10
debug_port = COM9
debug_tool = blackmagic
upload_port = COM5
upload_protocol = sam-ba
debug_load_cmd = preload
debug_load_mode = always
; debug_init_break = C:\Users\<Your Username>\.platformio\packages\framework-arduinosam\cores\sam\main.cpp main
debug_init_cmds = 
  define pio_reset_halt_target
    mon reset halt
    flushregs
  end
  define pio_reset_target
    mon reset
  end
  target extended-remote COM9
  monitor tpwr enable
  monitor swdp_scan
  set mem inaccessible-by-default off
  attach 1
  interrupt