Open lauraflu opened 4 years ago
Update
I also tried using the J-Link GDB Server and I have the same problem, so it seems to be something more fundamental. I used the following settings:
platformio.ini
[platformio]
default_envs = jlink_debug_and_upload
[env:debug_jlink]
platform = atmelsam
framework = arduino
board = adafruit_metro_m0
debug_tool = custom
debug_port = :2331
debug_server =
/opt/SEGGER/JLink_V670e/JLinkGDBServerCLExe
-singlerun
-if
SWD
-select
USB
-port
2331
-device
GMF03xxx6xx
debug_init_cmds =
define pio_reset_halt_target
monitor reset
monitor halt
end
define pio_reset_run_target
monitor clrbp
monitor reset
monitor go
end
target extended-remote $DEBUG_PORT
monitor clrbp
monitor speed auto
pio_reset_halt_target
$LOAD_CMDS
$INIT_BREAK
[env:jlink_debug_and_upload]
platform = atmelsam
framework = arduino
board = adafruit_metro_m0
extra_scripts = extra_script.py
upload_protocol = custom
debug_tool = jlink
debug_server =
/opt/SEGGER/JLink_V670e/JLinkGDBServerCLExe
-singlerun
-if
SWD
-select
USB
-port
2331
-device
GMF03xxx6xx
If I do not set a custom breakpoint, it is set to the init()
line in the main.cpp
file and I am able to step over the lines until it hits the setup()
function and then it gets stuck in the Starting target CPU...
.
main.cpp
#define ARDUINO_MAIN
#include "Arduino.h"
// Weak empty variant initialization function.
// May be redefined by variant files.
void initVariant() __attribute__((weak));
void initVariant() { }
// Initialize C library
extern "C" void __libc_init_array(void);
/*
* \brief Main entry point of Arduino application
*/
int main( void )
{
init();
__libc_init_array();
initVariant();
delay(1);
#if defined(USE_TINYUSB)
Adafruit_TinyUSB_Core_init();
#elif defined(USBCON)
USBDevice.init();
USBDevice.attach();
#endif
setup();
for (;;)
{
loop();
yield(); // yield run usb background task
if (serialEventRun) serialEventRun();
}
return 0;
}
#if defined(USE_TINYUSB)
// run TinyUSB background task when yield()
extern "C" void yield(void)
{
tud_task();
tud_cdc_write_flush();
}
#endif
Hello, was this issue ever fixed? I have somewhat same issue while debugging my custom SAMD21G18AU board. In my situation the debugger works and steps through until initVariant(). If i step over the delay(1) statement the debugger automatically steps into _malloc_r.dbgasm and the XPSR interrupt number is set to 0x03 (Hard Fault??).
OS: Pop!_OS 20.04 LTS x86_64 Debugger: J-link EDU V10.10 IDE: Visual studio Code
[env:zero]
platform = atmelsam
board = zero
framework = arduino
upload_protocol = jlink
debug_tool = jlink
The upload seems to work but I do not see the code executing (uploaded a simple led blink program).
I have verified my board works by other means (uploading and debugging using the visualgdb extension for visual studio works flawlessly)
I have experienced somewhat similar issue while using the internal debugger jlink present in another development board #https://github.com/platformio/platform-nordicnrf52/issues/91#issuecomment-677777818
Regards
Hello! I did not get any more help than what you see here. In the end, I managed to debug the board while still compiling with platformio but using gdb (I wrote a guide for posterity here about how to do it). I needed to debug a bigger project which uses platformio, but I didn't care too much about the debugging tool I'm using. Anyway, I'm not sure if the fact that this worked means that the problem is not with platformio itself, but with the Visual Studio interface.
Hello! I did not get any more help than what you see here. In the end, I managed to debug the board while still compiling with platformio but using gdb (I wrote a guide for posterity here about how to do it). I needed to debug a bigger project which uses platformio, but I didn't care too much about the debugging tool I'm using. Anyway, I'm not sure if the fact that this worked means that the problem is not with platformio itself, but with the Visual Studio interface.
I'd like to go with the last statement, just tested uploading and debugging via the Atom IDE and it works. Something really is rotten in Visual studio code. @valeros maybe this is worth looking into?
In this case, perhaps it's better to post the issue on platformio-vscode-ide?
I've run into basically the same issue, although with a generic Nordic nRF52832 board. However, it is only Zephyr that has this issue through VS Code -- if I try to debug a sample Arduino or Mbed application with the same board and the same J-Link, the debugger works properly.
@CzzzViewer , do you have information regarding settings for VS Code? You seem to be referring to an Eclipse solution.
In case anyone else runs into this problem, try adding this line to your environment in platformio.ini
:
debug_build_flags = -O0 -ggdb2 -g2
For me it was the optimization flag -Og
(the PlatformIO default) that was the problem. Changing that to -O0 allows debugging to work correctly.
I've run into basically the same issue, although with a generic Nordic nRF52832 board. However, it is only Zephyr that has this issue through VS Code -- if I try to debug a sample Arduino or Mbed application with the same board and the same J-Link, the debugger works properly.
@CzzzViewer , do you have information regarding settings for VS Code? You seem to be referring to an Eclipse solution.
Oh, Yes, You are totally right. My post was about Eclipse and it was in the wrong place. Sorry for the confusion.
Configuration
Operating system: Ubuntu 19.10
PlatformIO Version (
platformio --version
): 4.3.1Description of problem
I am trying to debug an Adafruit Metro M0 Express board using a Segger J-Link Edu Mini debugger. Uploading the firmware works fine through the J-Link, but when I start the debugging, whatever I do (step into, step over, continue, etc.) after the first breakpoint, I get the console message
Starting target CPU...
and the debugging is stuck at this stage. I used Visual Studio Code, but I tried debugging in the console as well without success.Steps to Reproduce
Actual Results
Debug console:
Expected Results
Expect to step into the function or continue running, depending on the given command. But it simply hangs in this
Starting target CPU...
state.The content of
platformio.ini
:Source file to reproduce issue (the arduino-blink example):
Additional info
I've just bought the J-Link debug probe and this is the first time I'm using it. I've updated the firmware, but I haven't tried using it with any other board. It works for uploading the firmware to the board, just not for debugging. I'm not sure if it's a problem with the platform or with the PlatformIO core.
Any help is greatly appreciated. Thank you!