14

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:

enter image description here

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.

Improve this question

3 Answers 3

Reset to default
29

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

enter image description here

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Just a note: This behavior is the default of CubeMX. Actually, on power up, hardware sets these pins as SWD & JTAG pins. So, they are programing pins by default, but Cube framework disables them during initialization.
Looks like for an STM32F3DISCOVERY board, the PC4 pin needs to be set to TX and the PC5 pin needs to be set to RX in the Pinout view. I deduced this from Section 6.2.3 on page 15/36 of the UM1570 User manual for the STM32F3DISCOVERY kit. It's pretty much just magic handwaving to me but this answer helped me to stumble into something that seems to work. st.com/content/ccc/resource/technical/document/user_manual/8a/…
See as well this guide discussing the SWD header, stm32-base.org/guides/connecting-your-debugger.html
4

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.

Improve this answer

2 Comments

"Reset Mode = Software system reset." worked for me
"Software System Reset" did it for me. I have applied it in the STM32CubeIDE (1.6.0) -> Debug Configurations -> Debugger tab -> Reset Behavior .
2

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.