STM32CubeIDE can only flash once, no SWD debugging

Question

For a couple of years I have been using the mbed online compiler to create .bin files, and then flash them at the command line like this, using a ST-LINK/V2 USB dongle, and everything works flawlessly:

st-flash write 01_blink.NUCLEO_F103RB.bin 0x8000000

Today I downloaded the STM32CubeIDE for Linux (Fedora 30) and started going through this tutorial, using a maple mini (STM32F103CBT6).

https://www.digikey.co.nz/en/maker/projects/getting-started-with-stm32-introduction-to-stm32cubeide/6a6c60a670c447abb90fd0fd78008697

After building the project and starting a debug run, I get the output:

STMicroelectronics ST-LINK GDB server. Version 5.3.2
Copyright (c) 2019, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

Waiting for debugger connection...
Debugger connected
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.2.0                  
      -------------------------------------------------------------------



Log output file:   /tmp/STM32CubeProgrammer_2ZxzGk.log
ST-LINK SN  : 34006B063058373138650943
ST-LINK FW  : V2J34S7
Voltage     : 3.21V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x410
Device name : STM32F101/F102/F103 Medium-density
Flash size  : 64 KBytes
Device type : MCU
Device CPU  : Cortex-M3



Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_Q2zZSF.srec
  File          : ST-LINK_GDB_server_Q2zZSF.srec
  Size          : 4648 Bytes
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:00.595



Verifying ...




Download verified successfully 


Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Target is not responding, retrying...
Error! Failed to read target status 
Debugger connection lost.
Shutting down...

After that I can no longer start a debug session because I get this:

I can see the LED blinking as expected so I know the program was actually flashed to the board ok. But I can't do anything further with STM32CubeIDE and when I try to flash via the command line as before, now that doesn't work either:

[root@localhost Downloads]# st-flash write 01_blink.NUCLEO_F103RB.bin 0x8000000 
st-flash 1.5.1-38-gc3577b5
2020-03-24T13:51:09 INFO common.c: Loading device parameters....
2020-03-24T13:51:09 WARN common.c: Invalid flash type, please check device declaration
  core status: unknown
Unknown memory region

Fortunately I can return to my starting point by using ST-Link UTILITY (on Windows) and holding the reset button before connecting, then doing a full erase, as mentioned here:

http://www.kerrywong.com/2012/08/02/the-dreaded-cannot-connect-to-st-link-error-message/

But obviously this is not a viable situation for getting any productive development done. What am I doing wrong?

In the 'Debugger' tab of the 'Debug configurations' dialog, I have tried setting 'Interface' as SWD (it was already actually) and I've also tried all options for 'Reset behaviour', with no change in outcome.

Answer 1

Why does this always happen? I struggle with something for a few hours, then spend another 20 minutes making as concise and clear question as I can with screenshots etc, then two minutes after posting I find the answer, usually in another SO answer that I somehow never saw in hours of searching. I think about half of the questions I've asked on SO ended up this way.

The problem seems to be that unless you declare that you want to use SWD and on what pins, it will not be enabled by default. So as soon as the new program is flashed the SWD connection goes dead. I guess the mbed program retains the use of SWD on the standard pins by default so it was never an issue there.

Anyway to avoid this, go back to the pinout and configuration (double-click the .ioc file in the project explorer). Set the appropriate pins for SWD (PA13, PA14 in my case), and under 'System Core', click SYS and set the Debug option to 'Serial Wire'.

Answer 2

Yes, that is correct iforce2d. Once you have the Serial Wire- Debug enabled, you can now flash your new program to the board (inside the IDE) without the need to first erase everything using the ST-Link Utility.

Follow these steps :

1. Connect BOOT0 pin to high (3.3v) – The Blue Pill board conveniently has a jumper for this. (Not sure about the maple mini)
2. Press the Reset button.
3. Build & Run your new program (in the STM32CubeIDE).
4. Return the jumper to zero.

Once you have a program in the STM32 that has the SWD pins enabled then you will no longer be “locked out”, so you don’t need to use BOOT0 (or Reset) again after this…

Note: Debug Configuration (that works best for me): Debug probe = ST-LINK (OpenOCD) ; Reset Mode = Software system reset.

Answer 3

In my case (STM32F429I-DISC) I found that one of pins that are used in SWD was by mistake assigned by me for another purpose. I released it and debug starts to work. I just found the schematic for the ST board and check what pins are used for SWD.