Target Halted Due to debug-request

Hi! I setup my first PlatformIO project recently, but I have been running into the following issue after attempting to upload. I am using this board, the PlatformIO extension for VSCode and I’m on MacOS 10.15.7.

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/nucleo_f302r8.html
PLATFORM: ST STM32 (10.0.1) > ST Nucleo F302R8
HARDWARE: STM32F302R8T6 72MHz, 16KB RAM, 64KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, cmsis-dap, jlink)
PACKAGES: 
 - framework-arduinoststm32 4.10900.200819 (1.9.0) 
 - framework-cmsis 2.50501.200527 (5.5.1) 
 - tool-dfuutil 1.9.200310 
 - tool-openocd 2.1000.200630 (10.0) 
 - tool-stm32duino 1.0.1 
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/nucleo_f302r8/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   5.7% (used 928 bytes from 16384 bytes)
Flash: [==        ]  16.0% (used 10516 bytes from 65536 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/nucleo_f302r8/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800074c msp: 0x20004000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
==================================================================================================================== [SUCCESS] Took 4.69 seconds ====================================================================================================================

Terminal will be reused by tasks, press any key to close it.

I am using the default platformio.ini file:

[env:nucleo_f302r8]
platform = ststm32
board = nucleo_f302r8
framework = arduino

My main.cpp compiles successfully and I can run openocd -f stlink-v2.cfg -f stm32f3x.cfg via my homebrew installation. (Full file paths removed for brevity) The resulting output is:

Open On-Chip Debugger 0.11.0-rc1+dev-01530-g0dd3b7fa6-dirty (2020-12-19-18:22)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J37M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.261782
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f3x.cpu on 3333
Info : Listening on port 3333 for gdb connections

Running brew info openocd:

open-ocd: stable 0.10.0 (bottled), HEAD
On-chip debugging, in-system programming and boundary-scan testing
http://openocd.org/
/usr/local/Cellar/open-ocd/HEAD-0dd3b7f (800 files, 4.7MB) *
  Built from source on 2020-12-19 at 18:23:23
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/open-ocd.rb
License: GPL-2.0
==> Dependencies
Build: pkg-config ✔
Required: hidapi ✔, libftdi ✔, libusb ✔, libusb-compat ✔
==> Options
--HEAD
	Install HEAD version
==> Analytics
install: 580 (30 days), 1,825 (90 days), 7,173 (365 days)
install-on-request: 577 (30 days), 1,801 (90 days), 7,104 (365 days)
build-error: 0 (30 days)

I do notice that Platformio: Upload is using a different version of openocd (0.10.0+dev-00378-ge5be992df (2020-06-26-12:31) than the working brew version (0.11.0-rc1+dev-01530-g0dd3b7fa6-dirty (2020-12-19-18:22). I was unable to customize it to use the working version of openocd. I attempted to tell platformio to use my brew openocd (full file paths removed for brevity) however the output after uploading still did not change. My updated platformio.ini file is shown below but that had no affect and the .platformio/packages/tool-openocd version still gets used.

[env:nucleo_f302r8]
platform = ststm32
board = nucleo_f302r8
framework = arduino
debug_tool = custom
debug_server = 
	openocd
	-f
	stlink-v2.cfg
	-f
	stm32f3x.cfg

Any feedback would be greatly appreciated!

Hi udit8348, also my first dabble with PlatformIO this past week coming from Arduino IDE background…

I went with a simple Blink LED on a NUCLEO-F401RE with onboard ST-Link, and our Terminal output is near identical except for the different board yet no blinking LED.

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/nucleo_f401re.html
PLATFORM: ST STM32 (10.0.1) > ST Nucleo F401RE
HARDWARE: STM32F401RET6 84MHz, 96KB RAM, 512KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, cmsis-dap, jlink)
PACKAGES: 
 - framework-arduinoststm32 4.10900.200819 (1.9.0) 
 - framework-cmsis 2.50501.200527 (5.5.1) 
 - tool-dfuutil 1.9.200310 
 - tool-openocd 2.1000.200630 (10.0) 
 - tool-stm32duino 1.0.1 
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/nucleo_f401re/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.9% (used 880 bytes from 98304 bytes)
Flash: [          ]   2.0% (used 10732 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/nucleo_f401re/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:27)
Licensed under GNU GPL v2

debug_level: 1

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000858 msp: 0x20018000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
================ [SUCCESS] Took 5.35 seconds ===

My Platform.ini is…

[env:nucleo_f401re]
board = nucleo_f401re
platform = ststm32
framework = arduino
upload_protocol = stlink
debug_tool = stlink
upload_port = /dev/ttyACM0

Out of frustration I thought I’ll try one of the other ‘frameworks’, found this example [STM32Cube HAL and Nucleo-F401RE: debugging and unit testing — PlatformIO latest documentation] and ‘lo and beholed’ it worked… Even the debugging… :slight_smile:

Perhaps try it just to confirm things are working, while you wait for an answer to your question…

The upload via openocd worked. Do you have a bug with this particular OpenOCD version that PlatformIO is using?

This only affects debugging, not uploading. For that you would have to modify upload_cmd and include the necessary flags to incorporate programming the firmware image.

But actually, you should not need to customize any of the debug_tool or upload commands. They’re defaulting to STLink already and uploading works as you proved yourself. Debugging in VSCode should work too with Run → Start debugging without problems.

Why do you think it’s not working?

If your firmware is not running as expected, please post the full code of it.

Setting upload_port to a serial port while doing the STLink upload protocol makes no sense. The STLink is a USB device and as thus will be autodetected. The virtual COM port (VCP) opened by the STLink is only used for communicating via UART, not to upload the firmware. I think you want this as a monitor_port or not at all because PlatformIO can auto-detect this.

What code are you using?

Thx for editing my post… :slight_smile:

I’ve used the code out of ‘Project Examples’ called arduino-blink (have tried many others), I see ‘LED_BUILTIN’ does expand PA5 my boards led pin.

/*
 * Blink
 * Turns on an LED on for one second,
 * then off for one second, repeatedly.
 */

#include <Arduino.h>

void setup()
{
  // initialize LED digital pin as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  // turn the LED on (HIGH is the voltage level)
  digitalWrite(LED_BUILTIN, HIGH);
  // wait for a second
  delay(1000);
  // turn the LED off by making the voltage LOW
  digitalWrite(LED_BUILTIN, LOW);
   // wait for a second
  delay(1000);
}

Here is the Arduino code that I tried:

#include <Arduino.h>

void setup() {
  pinMode(GPIO_PIN_13, OUTPUT);
}

void loop() {
  digitalWrite(GPIO_PIN_13, LOW);
  delay(1000);
  digitalWrite(GPIO_PIN_13, HIGH);
  delay(1000);
}

This is the output that I get when I upload. (openocd version 0.10.0...). Using this method, I do no see any blinking led on the board.

CURRENT: upload_protocol = stlink
Uploading .pio/build/nucleo_f302r8/firmware.elf
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-12:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080005ec msp: 0x20004000
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

I set up a similar project with the STM32-for-vscode extension. Using their upload command, I got the following output. This time the led blinked as expected. I was able to tell it to use my brew installation of openocd (version 0.11.0...). Seems like the openocd messages are very similar, so that might not be the issue.

> Executing task in folder test-project: make -f STM32Make.make flash <

openocd -f interface/stlink.cfg  -f target/stm32f3x.cfg -c "program build/test-project.elf verify reset exit"
Open On-Chip Debugger 0.11.0-rc1+dev-01530-g0dd3b7fa6-dirty (2020-12-19-18:22)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J37M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.255900
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f3x.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080005ec msp: 0x20004000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10016439
Info : flash size = 64kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
shutdown command invoked

The code I used this time was:

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_USART2_UART_Init();
  
  while (1)
  {
    HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_SET);
    HAL_Delay(1000);
    HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_RESET);
    HAL_Delay(1000);
  }
}

Perhaps I am not setting up the Arduino framework correctly as @fek9 suggested. I should also mention that I generated a makefile from STMCubeMX and then used STM32-for-VSCode’s setup scripts to configure the entire workspace so the only code that I wrote myself were the lines inside the while loop.

You cannot (should not if you want it to work) use GPIO_PIN_X values from the STM32HAL for the digtialWrite() or pinMode functions of Arduino. Also this would be missing which GPIO bank it is. Like GPIOA and pin 13 is PA13, but how is only with the pin info supposed to know if you don’t want PC13?

The pinMode and digitalWrite and friends functions go through a pin mapping that turns an absolute pin number / macro into the port + pin information, e.g. “17” = PC12.

The exact pin name to numbers mapping can be seen at

https://github.com/stm32duino/Arduino_Core_STM32/blob/master/variants/NUCLEO_F302R8/variant.h#L93-L95

https://github.com/stm32duino/Arduino_Core_STM32/blob/master/variants/NUCLEO_F302R8/variant.h#L43-L43

say that LED_BUILTIN maps to pin PB13.

This matches the information found on NUCLEO-F302R8 | Mbed (CN5 connector).

for this particular variant.

However, you should never use the numerical values directly. Always their symbolic name.

The Nucleo F302R8, as the on board LED pin on D13 (arduino pin name) or PB13. The LED is also mapped to the LED_BUILTIN macro.

So please try this code @udit8348

#include <Arduino.h>

//#define LED LED_BUILTIN
#define LED PB13

void setup() {
  pinMode(LED, OUTPUT);
}

void loop() {
  digitalWrite(LED, LOW);
  delay(1000);
  digitalWrite(LED, HIGH);
  delay(1000);
}

Either macro value works.

1 Like

Based on this

This should be correct. PA5 is where the LED should be at. Can you still replace LED_BUILTIN with PA5?

PA_5 expands to "enum PinName::PA_5 = 5"

PA5 expands to 13

LED_BUILTIN expands to PA5

Yes this has been tried before…:slight_smile:

Since my debug was working I thought I’ll try F5 ‘Start Debugging’ on the above BlinkLed main.cpp, the compiling was successful then it crossed over to the DEBUG CONSOLE…

On the debug console two errors showed, I’ve copied and pasted them below…

_Error_Handler (msg=msg@entry=0x8002e34 "/home/FeK9/.platformio/packages/framework-arduinoststm32/variants/NUCLEO_F4x1RE/variant.cpp", val=val@entry=148) at /home/FeK9/.platformio/packages/framework-arduinoststm32/libraries/SrcWrapper/src/stm32/stm32_def.c:18
    18	  }

also towards the end of the debug output listing this line.

Temporary breakpoint 1 at 0x8000a5e: file /home/FeK9/.platformio/packages/framework-arduinoststm32/cores/arduino/main.cpp, line 50.

Had look at the above main.cpp, the PROBLEM CONSOLE showed 1 issue attribute
"constructor" does not take arguments C/C++ (1094) [25, 27]

Not sure if the above is related to the program not working corectly?

Also ran into 3 #included ‘Intellisense’ phantom squiggles, rip out the ‘framework-arduinoststm32’ because of it then reinstalled it. Still the same phantoms, then learn about ‘Intellisense’ phantom squiggles then rebuilt the index…

Hm you’re definitively hitting the error handler there.

That is the initVariant() call. Can you use step-by-step debugging starting from main() to
see in which point it goes into the error handler? Or better, can you set a breakpoint at _Error_Handler() in /home/FeK9/.platformio/packages/framework-arduinoststm32/libraries/SrcWrapper/src/stm32/stm32_def.c:18 and then give a screenshot of the backtrace in the debugger to see why it went there?

I have a feeling it’s failing in some low-level initialization stuff, like clock setup.

That makes, sense now. I tried your sample code with both macros and it works as expected. Thanks!

Hi @udit8348 sorry for unintentionally hijacking your forum post, maxgerhardt answered us both… :slight_smile:

At lest both of us got our boards to Led Blink, you via STM32-for-vscode extension (STM CubeMX) and me via ‘framework = stm32cube’ (STM CubeMX)…

I’m wondering if you have the time to experiment / tinker if your debug side of your board is working…?

We both start with with our main.cpp as…

/*
 * Blink
 * Turns on an LED on for one second,
 * then off for one second, repeatedly.
 */

#include <Arduino.h>

void setup()
{
  // initialize LED digital pin as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  // turn the LED on (HIGH is the voltage level)
  digitalWrite(LED_BUILTIN, HIGH);
  // wait for a second
  delay(1000);
  // turn the LED off by making the voltage LOW
  digitalWrite(LED_BUILTIN, LOW);
   // wait for a second
  delay(1000);
}

and see if our debugging result differ, you using MacOS and me MxLinux a Linux Mint / Debian derivative…

I started tinkering a week ago with PlatformIO because I was needing a little debugging, the last time I saw a debugger was with MPLAB and PICs at lest 15 years ago…

I try understand a more formal ‘backtrace’ with debugger (OpenOCD) in the next few days with research. I’m at the edge of my understanding… :slight_smile:

But with pausing I did hit this?

/home/FeK9/.platformio/packages/framework-arduinoststm32/libraries/SrcWrapper/src/stm32/stm32_def.c

Line 13 to 18 of the above mention file…

WEAK void _Error_Handler(const char *msg, int val)
{
  /* User can add his own implementation to report the HAL error return state */
  core_debug("Error: %s (%i)\n", msg, val);
  while (1) {
  }
}

I recognize while (1) { } on line 17…?

Hi @fek9, no worries about the thread topic! I actually got Platformio working too, after implementing the macros that were suggested in this post.

I set a break point on the first digitalWrite line and this was the output that I got after stepping over several times, then stopping the debug.

Processing nucleo_f302r8 (platform: ststm32; board: nucleo_f302r8; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/nucleo_f302r8.html
PLATFORM: ST STM32 (10.0.1) > ST Nucleo F302R8
HARDWARE: STM32F302R8T6 72MHz, 16KB RAM, 64KB Flash
DEBUG: Current (custom) On-board (stlink) External (blackmagic, cmsis-dap, jlink)
PACKAGES:
 - framework-arduinoststm32 4.10900.200819 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio/build/nucleo_f302r8/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   5.7% (used 936 bytes from 16384 bytes)
Flash: [==        ]  19.7% (used 12928 bytes from 65536 bytes)
========================= [SUCCESS] Took 2.33 seconds =========================
Reading symbols from /Users/udit/Documents/PlatformIO/Projects/blinky/.pio/build/nucleo_f302r8/firmware.elf...
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = custom
PlatformIO: Initializing remote target...
Open On-Chip Debugger 0.11.0-rc1+dev-01530-g0dd3b7fa6-dirty (2020-12-19-18:22)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 1000 kHz
Info : STLINK V2J37M26 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.255900
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f3x.cpu on pipe
Info : accepting 'gdb' connection from pipe
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x08000b22 msp: 0x20003fe0
Info : device id = 0x10016439
Info : flash size = 64kbytes
delay (ms=500, ms@entry=1000) at /Users/udit/.platformio/packages/framework-arduinoststm32/cores/arduino/wiring_time.c:43
43	    } while (getCurrentMillis() - start < ms);
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000974 msp: 0x20004000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0x2cdc lma 0x8000188
Loading section .rodata, size 0x51c lma 0x8002e64
Loading section .init_array, size 0x14 lma 0x8003380
Loading section .fini_array, size 0x8 lma 0x8003394
Loading section .data, size 0x88 lma 0x800339c
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000974 msp: 0x20004000
Start address 0x8000974, load size 13348
Transfer rate: 18 KB/sec, 2224 bytes/write.
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000974 msp: 0x20004000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000974 msp: 0x20004000
Temporary breakpoint 1 at 0x8000952: file /Users/udit/.platformio/packages/framework-arduinoststm32/cores/arduino/main.cpp, line 50.
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.

Temporary breakpoint 1, main () at /Users/udit/.platformio/packages/framework-arduinoststm32/cores/arduino/main.cpp:50
50	  initVariant();
Info : halted: PC: 0x08000956
halted: PC: 0x08000956
Info : halted: PC: 0x08002b88
halted: PC: 0x08002b88
Info : halted: PC: 0x08002b8c
halted: PC: 0x08002b8c
Info : halted: PC: 0x08002b8e
halted: PC: 0x08002b8e
Info : halted: PC: 0x080009c8
halted: PC: 0x080009c8
Info : halted: PC: 0x080009ce
halted: PC: 0x080009ce
Info : halted: PC: 0x080009d0
halted: PC: 0x080009d0
Info : halted: PC: 0x080009d2
halted: PC: 0x080009d2
Info : halted: PC: 0x080009d6
halted: PC: 0x080009d6
Info : halted: PC: 0x080009da
halted: PC: 0x080009da
Info : halted: PC: 0x080009dc
halted: PC: 0x080009dc
Info : halted: PC: 0x080009e0
halted: PC: 0x080009e0
Info : halted: PC: 0x080009e2
halted: PC: 0x080009e2
Info : halted: PC: 0x080009e6
halted: PC: 0x080009e6
Info : halted: PC: 0x080009ea
halted: PC: 0x080009ea
Info : halted: PC: 0x080009ec
halted: PC: 0x080009ec
Info : halted: PC: 0x080009f0
halted: PC: 0x080009f0
Info : halted: PC: 0x080009f2
halted: PC: 0x080009f2
Info : halted: PC: 0x080009f4
halted: PC: 0x080009f4
Info : halted: PC: 0x080009f6
halted: PC: 0x080009f6
Info : halted: PC: 0x08000a76
halted: PC: 0x08000a76
Info : halted: PC: 0x08000a78
halted: PC: 0x08000a78
Info : halted: PC: 0x08000a7a
halted: PC: 0x08000a7a
Info : halted: PC: 0x08002380
halted: PC: 0x08002380
Info : halted: PC: 0x08000a56
halted: PC: 0x08000a56
Info : halted: PC: 0x08002b92
halted: PC: 0x08002b92
Info : halted: PC: 0x0800095a
halted: PC: 0x0800095a
Info : halted: PC: 0x08002b94
halted: PC: 0x08002b94

Breakpoint 2, loop () at src/main.cpp:10
10	  digitalWrite(LED, HIGH);
Info : halted: PC: 0x08002b98
halted: PC: 0x08002b98
Info : halted: PC: 0x08002b9a
halted: PC: 0x08002b9a
Info : halted: PC: 0x08000aac
halted: PC: 0x08000aac
Info : halted: PC: 0x08002ba2
halted: PC: 0x08002ba2
Info : halted: PC: 0x08000b10
halted: PC: 0x08000b10
pio_reset_run_target
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Unable to match requested speed 1000 kHz, using 950 kHz
[Inferior 1 (Remote target) detached]

Okay so you hit this line but what is the backtrace? Usually shown in the lower left corner of the VSCode Debugging screen, as a list of functions and line numbers

Hi maxgerhardt

I think this is what you are looking for

VARIABLES
Local

msg: 0x8002e34 "/home/FeK9/.platformio/packages/framework-arduinoststm32/variants/NUCLEO_F4x1RE/variant.cpp"
	*msg: 47 '/'

msg@entry: 0x8002e34 "/home/FeK9/.platformio/packages/framework-arduinoststm32/variants/NUCLEO_F4x1RE/variant.cpp"

	*msg@entry: 47 '/'
	val: 148
	val@entry:148


CALL STACK

_Error_Handler@0x08002084 (/home/FeK9/.platformio/packages/framework-arduinoststm32/libraries/SrcWrapper/src/stm32/stm32_def.c:18)

SystemClock_Config@0x080002ba (/home/FeK9/.platformio/packages/framework-arduinoststm32/variants/NUCLEO_F4x1RE/variant.cpp:148)

hw_config_init@0x08001c26 (/home/FeK9/.platformio/packages/framework-arduinoststm32/libraries/SrcWrapper/src/stm32/hw_config.c:63)

init@0x08000a4a (/home/FeK9/.platformio/packages/framework-arduinoststm32/cores/arduino/board.c:11)

premain@0x08000a5a (/home/FeK9/.platformio/packages/framework-arduinoststm32/cores/arduino/main.cpp:42)

__libc_init_array@0x080029c8 (/__libc_init_array.dbgasm:24)

Reset_Handler@0x08000ab2 (/home/FeK9/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f401xe.s:111)

For interest sake I started step down the ‘platform = ststm32’ version via platformio.ini. Going 9.0 8.0.7.0 then when I hit ‘platform = ststm32@6.0’ my Blinking Led example started working… :slight_smile:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/nucleo_f401re.html
PLATFORM: ST STM32 (10.0.1) > ST Nucleo F401RE
HARDWARE: STM32F401RET6 84MHz, 96KB RAM, 512KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, cmsis-dap, jlink)
PACKAGES: 
 - framework-arduinoststm32 4.10900.200819 (1.9.0) 
 - framework-cmsis 2.50501.200527 (5.5.1) 
 - tool-dfuutil 1.9.200310 
 - tool-openocd 2.1000.200630 (10.0) 
 - tool-stm32duino 1.0.1 
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 10 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/nucleo_f401re/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.9% (used 880 bytes from 98304 bytes)
Flash: [          ]   2.0% (used 10732 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/nucleo_f401re/firmware.elf

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/nucleo_f401re.html
PLATFORM: ST STM32 (6.0.0) > ST Nucleo F401RE
HARDWARE: STM32F401RET6 84MHz, 96KB RAM, 512KB Flash
DEBUG: Current (stlink) On-board (stlink) External (blackmagic, jlink)
PACKAGES: 
 - framework-arduinoststm32 3.10700.191028 (1.7.0) 
 - tool-dfuutil 1.9.200310 
 - tool-openocd 2.1000.200630 (10.0) 
 - tool-stm32duino 1.0.1 
 - toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 8 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/nucleo_f401re/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.9% (used 880 bytes from 98304 bytes)
Flash: [          ]   2.4% (used 12444 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio/build/nucleo_f401re/firmware.elf