search

platformio / platformio-core

Your Gateway to Embedded Software Development Excellence :alien:
https://platformio.org
Apache License 2.0
7.97k stars 797 forks source link

Debugging with blackmagicprobe crashes at start. #4932

Open positron96 opened 5 months ago

positron96 commented 5 months ago

What kind of issue is this?

You can erase any parts of this template not applicable to your Issue.

Configuration

Operating system: Win 10 x64

PlatformIO Version (platformio --version): PlatformIO Core, version 6.1.15

Description of problem

I've setup a project with STM32G030 MCU with blackmagicprobe used as debugger/uploader. The MCU has been programmed and debugged fine for a month, but at some point I noticed that debugging fails right at the start.

The error in VSCode Debug console is

Remote failure reply: EE02000000000000FFFFFFFFFFFFFFFFD0020020FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEE02000000200020DB1B0008B01A00080000006100200020FCFFFFFF00000000

Uploading firmware via BMP from PlatformIO still works. Uploading and debugging with stlink from PlatformIO also works fine. I tried to use GDB to issue commands to BMP directly, and it seems to work fine. At least I was able to connect, select elf, reset, start/stop/step the program manually. Though I don't quite know what commands pio sends when debugging and what command causes the crash.

If I go back in git history, previous versions of my code can be debugged properly, so the problem shows for a combination of specific source + BMP + PlatformIO.

At the moment I would like to not disclose the source code unless absolutely necessary, and it could be tied to my specific BMP hardware/software version. So it will be hard to reproduce, so I am prepared to do some troubleshooting myself (I vaguely remember having GDB communication somewhere in vscode output tabs, but it's not there now. It would be rather useful for troubleshooting).

Steps to Reproduce

  1. In vscode, go to Debug tab and execute "PIO Debug" configuration.

Actual Results

The code is compiled, uploaded, a debugging section is started, "current line" is highlighted in source code editor (it's in initial assembly code)

The error appears in vscode debugging console, no further debug actions are possible except killing the debug session.

Full output of vscode Debug console

``` Reading symbols from d:\Documents\PlatformIO\Projects\motorboard\.pio\build\motorboard\firmware.elf... done. PlatformIO Unified Debugger -> https://bit.ly/pio-debug PlatformIO: debug_tool = blackmagic PlatformIO: Initializing remote target... Target voltage: 3.28V Available Targets: No. Att Driver 1 STM32G03/4 M0+ LL_mDelay (Delay=Delay@entry=1) at C:\Users\positron\.platformio\packages\framework-stm32cubeg0\Drivers\STM32G0xx_HAL_Driver\Src\stm32g0xx_ll_utils.c:183 183 while (tmpDelay != 0U) Loading section .isr_vector, size 0xb8 lma 0x8000000 Loading section .text, size 0x2f7c lma 0x80000b8 Loading section .rodata, size 0x1a0 lma 0x8003034 Loading section .init_array, size 0x10 lma 0x80031d4 Loading section .fini_array, size 0x4 lma 0x80031e4 Loading section .data, size 0x88 lma 0x80031e8 Start address 0x8001ba4, load size 12912 Transfer rate: 25 KB/sec, 717 bytes/write. Temporary breakpoint 1 at 0x8001ab0: file src\cube\Core\Src\main.c, line 73. Warning: the current language does not match this frame. PlatformIO: Initialization completed PlatformIO: Resume the execution to `debug_init_break = tbreak main` PlatformIO: More configuration options -> https://bit.ly/pio-debug Note: automatically using hardware breakpoints for read-only addresses. Remote failure reply: EE02000000000000FFFFFFFFFFFFFFFFD0020020FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEE02000000200020DB1B0008B01A00080000006100200020FCFFFFFF00000000 ```

ivankravets commented 4 months ago

Here is the init script https://github.com/platformio/platformio-core/blob/develop/platformio/debug/config/blackmagic.py

Could you help us to debug this issue?

positron96 commented 4 months ago

Yes, I'll try to reproduce the failing setup...

positron96 commented 3 weeks ago

Hi. Sorry it took so long to return to this issue. So, I am still experiencing this problem, and cannot reproduce it when manually running GDB commands. Here is my GDB session with commands generated by pio:

Details

``` C:\Users\positron\.platformio\packages\toolchain-gccarmnoneeabi\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. GNU gdb (xPack GNU Arm Embedded GCC, 64-bit) 8.3.1.20191211-git Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later 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-w64-mingw32 --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from D:\Documents\PlatformIO\Projects\motorboard\.pio\build\motorboard\firmware.elf... (gdb) define pio_reset_halt_target Type commands for definition of "pio_reset_halt_target". End with a line saying just "end". > set language c > set *0xE000ED0C = 0x05FA0004 > set $busy = (*0xE000ED0C & 0x4) > while ($busy) > set $busy = (*0xE000ED0C & 0x4) > end > set language auto >end (gdb) define pio_reset_run_target Type commands for definition of "pio_reset_run_target". End with a line saying just "end". > pio_reset_halt_target >end (gdb) define pio_restart_target Type commands for definition of "pio_restart_target". End with a line saying just "end". > pio_reset_halt_target > tbreak main > continue >end (gdb) target extended-remote COM3 Remote debugging using COM3 (gdb) monitor swdp_scan Target voltage: 3.28V Available Targets: No. Att Driver 1 STM32G03/4 M0+ (gdb) attach 1 Attaching to program: D:\Documents\PlatformIO\Projects\motorboard\.pio\build\motorboard\firmware.elf, Remote target LL_mDelay (Delay=Delay@entry=1) at C:\Users\positron\.platformio\packages\framework-stm32cubeg0\Drivers\STM32G0xx_HAL_Driver\Src\stm32g0xx_ll_utils.c:185 185 if ((SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk) != 0U) (gdb) set mem inaccessible-by-default off (gdb) load Loading section .isr_vector, size 0xb8 lma 0x8000000 Loading section .text, size 0x2fa4 lma 0x80000b8 Loading section .rodata, size 0x1a0 lma 0x800305c Loading section .init_array, size 0x10 lma 0x80031fc Loading section .fini_array, size 0x4 lma 0x800320c Loading section .data, size 0x88 lma 0x8003210 Start address 0x8001bcc, load size 12952 Transfer rate: 25 KB/sec, 719 bytes/write. (gdb) tbreak main Temporary breakpoint 1 at 0x8001ac8: file src\cube\Core\Src\main.c, line 73. (gdb) set language c Warning: the current language does not match this frame. (gdb) set *0xE000ED0C = 0x05FA0004 (gdb) set $busy = (*0xE000ED0C & 0x4) (gdb) while ($busy) > set $busy = (*0xE000ED0C & 0x4) >end (gdb) set language auto (gdb) c Continuing. Note: automatically using hardware breakpoints for read-only addresses. Temporary breakpoint 1, main () at src\cube\Core\Src\main.c:73 73 { (gdb) q A debugging session is active. Inferior 1 [Remote target] will be detached. Quit anyway? (y or n) y Detaching from program: D:\Documents\PlatformIO\Projects\motorboard\.pio\build\motorboard\firmware.elf, Remote target [Inferior 1 (Remote target) detached] ```

After running initialization commands, I did continue, successfully arrived at main breakpoint, which is already further than where PIO crashes. The same code (and the same elf) causes PIO to produce the error from issue description.