I have a generic STM32F103C8 board with a STLink v2 debugger and every time I start a debugging session it takes VERY long time to start. I timed it 92 sec. Yes, a minute and a half. That’s every single time. Just to start. Once connected, it seems to step, step over, etc, normally. ??? If I just plain upload, that goes normally in a few sec.
It’s a standard Dell desktop with no known problems, Win10 Pro. I have looked at and even reistalled the link drivers, no change. I have swapped out the board for another similar, no change. Platformio.ini is standard. Figured, maybe the link is bad. The mailman dropped me off one of those brand-new Nucleo STM32L476RG boards with built-in link and that is doing the the SAME THING. Very slow connecting again. But once connected, also seems to debug fine.
I have tried the same Blue Pill board and the STLink both with Keil and IAR evaluations and in both of those it connects almost instantly. So now I am thinking it cannot be the boards, the link or the drivers.
What else could be wrong? I realize it is free software but a 1.5 minutes?? Any pointers?
The only thing I could think of would be that it falsely recompiles. It should recompile once with debug settings to get you the right debug experience, but then no further recompilations should be made unless you do modifications to your source code.
What’s your platformio.ini? Can you show the logs two executions of pio debug in the commandline in the project folder?
Reading symbols from z:\My Projects\Miscellaneous\STM32F103C8_nRF24L01\.pio\build\bluepill_f103c8\firmware.elf...
done.
PlatformIO Unified Debugger -> **Edited out the link since it won't let me post it**
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD, 32-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-07:34)
Licensed under GNU GPL v2
For bug reports, read
Edited out the link since it won't let me post it
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 4000 kHz
Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.256576
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
target halted due to debug-request, current mode: Handler External Interrupt(18)
xPSR: 0x21000022 pc: 0x080001a6 msp: 0x20004fb0
Info : device id = 0x20036410
Info : flash size = 128kbytes
0x080001a6 in SystemClock_Config () at C:\users\admin\.platformio\packages\framework-arduinoststm32\variants\PILL_F103XX\variant.cpp:135
135 PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_ADC | RCC_PERIPHCLK_USB;
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000bbc msp: 0x20005000
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x6ddc lma 0x800010c
Loading section .rodata, size 0x62c lma 0x8006ee8
Loading section .progmem.data, size 0x20a lma 0x8007514
Loading section .init_array, size 0x1c lma 0x8007720
Loading section .fini_array, size 0x8 lma 0x800773c
Loading section .data, size 0x94 lma 0x8007744
Info : Padding image section 0 at 0x0800771e with 2 bytes
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
Start address 0x8005720, load size 30678
Transfer rate: 15 KB/sec, 3834 bytes/write.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
Temporary breakpoint 1 at 0x8000f4a: file C:\users\admin\.platformio\packages\framework-arduinoststm32\cores\arduino\main.cpp, line 56.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to `debug_init_break = tbreak main`
PlatformIO: More configuration options -> **Edited out the link**
Note: automatically using hardware breakpoints for read-only addresses.
Temporary breakpoint 1, main () at C:\users\admin\.platformio\packages\framework-arduinoststm32\cores\arduino\main.cpp:56
56 initVariant();
Thx,
Brian
PS. I noticed that Platformio being free software, uses Open OCD, whereas the commercial ones use ST stuff. Open OCD somehow wouldn’t be incompatible with my setup, wouldn’t it?
My ST Link V2 has firmware V2J36S7.
Building in debug mode
Linking .pio\build\bluepill_f103c8\firmware.elf
Checking size .pio\build\bluepill_f103c8\firmware.elf
Building .pio\build\bluepill_f103c8\firmware.bin
Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
RAM: [= ] 5.2% (used 1056 bytes from 20480 bytes)
Flash: [===== ] 45.6% (used 29852 bytes from 65536 bytes)
================================================================================================================================== [SUCCESS] Took 5.02 seconds ==================================================================================================================================
Terminal will be reused by tasks, press any key to close it.
After the last line it brings up the the debug workspace. Then the wait starts. On the upper left where it says RUN -> PIO Debug, I see a little green sliver running from left to right during the wait and pretty much that’s it. Nothing more happens until it hits and connects.
I am sorry if I didn’t describe it in more technical terms.
The code seems to work from what I can tell. All the buttons and the LED. And I can read data out of the radio STATUS register, etc. It uploads normally as far as I can tell. The only thing funny is the debugging.
Your description is good and narrows it down. To further narrow it down, can you switch to the DEBUG CONSOLE when the wait starts and describes what the output looks like during the wait?
This is what stays on DEBUG console for about a second. The the DEBUG console goes totally blank. Nothing. Then it waits…
Towards the end before it connects, it says what I pasted below. It spits out the whole Pulitzer and then it connects. The majority of the time, the screen stays blank.
Processing bluepill_f103c8 (framework: arduino; platform: ststm32; board: bluepill_f103c8)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: **Edited out**
PLATFORM: ST STM32 6.0.0 > BluePill F103C8
HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash
DEBUG: Current (stlink) External (blackmagic, jlink, stlink)
PACKAGES:
- framework-arduinoststm32 3.10700.191028 (1.7.0)
- toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> **Edited out**
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 11 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <RF24-STM>
| |-- <SPI> 1.0
Building in debug mode
Linking .pio\build\bluepill_f103c8\firmware.elf
Checking size .pio\build\bluepill_f103c8\firmware.elf
Building .pio\build\bluepill_f103c8\firmware.bin
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [= ] 5.2% (used 1056 bytes from 20480 bytes)
Flash: [===== ] 45.6% (used 29852 bytes from 65536 bytes)
========================= [SUCCESS] Took 5.92 seconds =========================
Reading symbols from z:\My Projects\Miscellaneous\STM32F103C8_nRF24L01\.pio\build\bluepill_f103c8\firmware.elf...
done.
PlatformIO Unified Debugger -> **Edited out**
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28)
Licensed under GNU GPL v2
For bug reports, read
**Edited out**
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 1000 kHz
Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.240714
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x0800576a msp: 0x20004fd0
Info : device id = 0x20036410
Info : flash size = 128kbytes
_Error_Handler (msg=msg@entry=0x80072d4 "C:\\Users\\ADMIN\\.platformio\\packages\\framework-arduinoststm32\\cores\\arduino\\HardwareTimer.cpp", val=val@entry=404) at C:\Users\ADMIN\.platformio\packages\framework-arduinoststm32\cores\arduino\stm32\stm32_def.c:14
14 {
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x6ddc lma 0x800010c
Loading section .rodata, size 0x62c lma 0x8006ee8
Loading section .progmem.data, size 0x20a lma 0x8007514
Loading section .init_array, size 0x1c lma 0x8007720
Loading section .fini_array, size 0x8 lma 0x800773c
Loading section .data, size 0x94 lma 0x8007744
Info : Padding image section 0 at 0x0800771e with 2 bytes
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
Start address 0x8005720, load size 30678
Transfer rate: 16 KB/sec, 3834 bytes/write.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08005720 msp: 0x20005000
Temporary breakpoint 1 at 0x8000f4a: file C:\Users\ADMIN\.platformio\packages\framework-arduinoststm32\cores\arduino\main.cpp, line 56.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to `debug_init_break = tbreak main`
PlatformIO: More configuration options -> **Edited out**
Note: automatically using hardware breakpoints for read-only addresses.
Temporary breakpoint 1, main () at C:\Users\ADMIN\.platformio\packages\framework-arduinoststm32\cores\arduino\main.cpp:56
56 initVariant();
I REALLY do like Platformio with VSC. I tip my hat to the people who wrote it. It’s fast, modular, has this sleek modern-looking interface, etc. And the best thing is, it’s totally bucks/pounds/roubles/pesos/shekels free. Just my two cents.
On a different topic, I think I am not alone with this slowness. There is another user here:
Just my two cents.