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'.