Trying to in-circuit debug BluePill program in VSCode 1.76.2 with PlatformIO

I want to do in-circuit debugging of my BluePill program with an STLink v2 dongle in VSCode but I don’t think it’s working. I can’t enter debugging mode unless Boot 0 is set to 1. If Boot 0 is set to 0, then I get this error when I click on Start Debugging:

“Failed to launch GDB: .pioinit:13: Error in sourced command file: Remote communication error. Target disconnected.: Success. (from interpreter-exec console “source .pioinit”)”.

If I set Boot 0 to 1 and click on Start Debugging, then it appears that the code compiles, uploads and enters debugging mode but the variables I’m watching don’t seem to change. To check, I added a counter which is meant to increment every time the main loop finishes but value seems to start at 64 and stay there. I’m expecting the value to change when I click run, wait a bit and then pause.

Also, when debugging starts, VScode opens this file: C:\Users\piter.platformio\packages\framework-arduinoststm32\variants\STM32F1xx\F103C8T_F103CB(T-U)\startup_M200_f103xb.S

I posted the entirety of my program here: #include <Arduino.h>#include <STM32RTC.h>#include <rtc.h>#include <STM32Lo - Pastebin.com

I’d appreciate any insight into what’s going wrong for me. Thanks in advance.

Version: 1.76.2 (user setup)
Commit: ee2b180d582a7f601fa6ecfdad8d9fd269ab1884
Date: 2023-03-14T17:55:54.936Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Windows_NT x64 10.0.19045

Does this also appear with these debug_build_flags?

Thanks for the suggestion. Should the line debug_build_flags = -O0 -ggdb3 -g3 be under [env:bluepill_f103c8] or under its own [env:debug] section?

The current state of my platformio.ini file, after adding an [env:debug] section is:

[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
framework = arduino
upload_protocol = stlink
build_type = debug
debug_tool = stlink
debug_init_break = tbreak setup
build_flags = 
	-D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC
	-D USBCON
	-D USBD_VID=0x0483
	-D USBD_PID=0x5740
	-D USB_MANUFACTURER="Unknown"
	-D USB_PRODUCT="\"BLUEPILL_F103C8\""
	-D HAL_PCD_MODULE_ENABLED
lib_deps = 
	stm32duino/STM32duino RTC@^1.3.6
	stm32duino/STM32duino Low Power@^1.2.3

[env:debug]
platform = ststm32
board = bluepill_f103c8
framework = arduino

; Set optimization level and amount of debug information generated by the compiler
debug_build_flags = -O0 -ggdb3 -g3

No need to create a own section. You add the option to the existing one. It’ll only be used during debugging anyways.

Attempting to debug after adding the debug_build_flags line to platformio.ini initially caused some errors while compiling. ChatGTP suggested adding ldscript.ld to my project with the following content:

MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  RAM : ORIGIN = 0x20000000, LENGTH = 20K
}

SECTIONS
{
  .text :
  {
    *(.text)
  } >FLASH

  .rodata :
  {
    *(.rodata)
  } >FLASH

  .data :
  {
    *(.data)
    . = ALIGN(4);
    _sidata = .;
    *(.data*)
    . = ALIGN(4);
    _edata = .;
  } >RAM AT> FLASH

  .bss :
  {
    . = ALIGN(4);
    _sbss = .;
    *(.bss*)
    . = ALIGN(4);
    _ebss = .;
  } >RAM

  .init :
  {
    KEEP(*(.init))
  } >FLASH
}

STACK_SIZE = 512;
_Min_Stack_Size = STACK_SIZE;
__Stack_Limit = ORIGIN(RAM) + LENGTH(RAM) - _Min_Stack_Size;
__stack = __Stack_Limit;
_estack = __stack;

PROVIDE(_sidata = LOADADDR(.text));
PROVIDE(_sdata = .);
PROVIDE(_edata = . + SIZEOF(.data));
PROVIDE(_sbss = .);
PROVIDE(_ebss = . + SIZEOF(.bss));
PROVIDE(_end = ORIGIN(RAM) + LENGTH(RAM));

as well as “board_build.ldscript = ldscript.ld” to platformio.ini and that made it compile and upload but now it’s back in the state it seemed to be before, with no variables changing, including the loopcounter variable which is stuck on -1061877760 from the beginning:

image

Could it be that the boot jumper is in the wrong place? I think boot 0 has to be in position 1 when programming but then position 0 to run the program, right? So am I supposed to unplug it after programming, move the jumper back and plug it back in? Thanks for your advice.