21
\$\begingroup\$

I have built my own board with STM32F7-45VGT6. I have successfully programmed it with ST-LINK v2 (not the original one though) and now I cannot even connect with MCU.

I use ST-Link Utility from ST and SWD interface. It can be the case that I use SWD pins as output and in my code I set them as GPIO output. Can it be the case?

Nevertheless, I connect my reset pin to GND and set "Connect under reset" option in ST-Link Utility but it doesn't work... What can I do?

On the Internet, I have found something about using BOOT0 Pin, but I don't know exactly...

\$\endgroup\$
1
  • \$\begingroup\$ "It can be the case that I use SWD pins as output" that's possible, but the only one who would know is you, unless you mean a corrupted load of a firmware that doesn't intentional do that, but might as a result of the error, which does indeed happen. Generally this is recoverable by performing the initial SWD connection with the hardware reset asserted, either manually or automatically. If you want to use the SWD pins as I/O's delaying a couple of seconds before making that setting may make development easier, but realize it still means you cannot use the debugger. \$\endgroup\$
    – Chris Stratton
    Commented Mar 18, 2017 at 18:03

8 Answers 8

Reset to default
31
\$\begingroup\$

I managed to solve that problem. If anybody encounters similar problem, here's what I've done:

I used ST-Link v2 and ST-Link Utility. In setting, I set "Connect under reset" and SWD interface (I'm not sure about frequency).
Then I press the reset button on my board and clicked "Target" -> "Erase chip" and just after clicking I released the button - It erased the chip so I can now reprogram my MCU.


Anyway, if you need to use SWD pins as output, then add some delay at the beginning of the program or use some jumper to disable/enable setting these pins as outputs.

\$\endgroup\$
3
  • \$\begingroup\$ Yes, that is pretty much to be expected if you use the SWD pins for a different purpose. Experience shows that even STM32 designs which don't intentionally do so can occasionally get "stuck" in a mode where the SWD pins are unresponsive (corrupted program?) and require such treatment for recovery. \$\endgroup\$
    – Chris Stratton
    Commented Dec 11, 2015 at 2:04
  • 1
    \$\begingroup\$ In linux, I used this bash command to erase the chip: st-flash erase \$\endgroup\$
    – nathan
    Commented Mar 31, 2018 at 18:32
  • 2
    \$\begingroup\$ The Erase chip didn't work for me. I went to Target -> Erase Sectors -> Select all -> apply. After this I regained access of my board. I'm not sure why the chip erase didn't word \$\endgroup\$
    – andrew
    Commented Aug 22, 2019 at 5:39
8
\$\begingroup\$

For connect under reset to work the ST-Link must have control over the reset pin, if you tie it to ground the ST-Link has no chance to get the target running and gain access to it.

If you pull the BOOT0 pin high during power up, the MCU will start into the internal bootloader and you can gain access using several serial protocols (see the reference manual for more details).

Inside the bootloader the SWD pins should be available to gain access, but I'm not 100% sure on this.

The ST Flash Loader Demonstrator is a tool which allows you to erase / program the micro using the UART interface. If you can't access any of the UARTs of your micro, this solution won't work for you.

\$\endgroup\$
7
  • \$\begingroup\$ I can access USART3 which is supported by the bootloader, so I will try that later - it will be tricky, cos BOOT0 is tied to GND on PCB... But I want to know what's wrong. What wrong have I done? I set SWD/JTAG pins as outputs in my main() function. But it says in manual that during reset all pins have their default function and can be used immediately. So why I can't erase flash under reset? I have also tested U-LINK 2 programmer and uVision 5. I hope that no protection level was - somehow accidentally - set. I didn't set any such bits, but is there any way to test if protections bits are ok? \$\endgroup\$
    – zupazt3
    Commented Dec 8, 2015 at 16:04
  • \$\begingroup\$ @zupazt3 I don't mean to sound rude, but please reread my first sentence. It contains an answer to the problem with the connect under reset. If you don't understand it, post a more specific comment. \$\endgroup\$
    – Arsenal
    Commented Dec 8, 2015 at 21:49
  • \$\begingroup\$ But I don't tie it all the time :) In my first post I meant that I EVEN tied it directly to GND to check if that would help. But normally I don't tie NRST to GND, but to a programmer, so it has control over reseting. And it still won't connect. I also tried to use U-Link 2 and Keil uVision 5 but with the same outcome. What can be the reason? \$\endgroup\$
    – zupazt3
    Commented Dec 8, 2015 at 22:25
  • \$\begingroup\$ @zupazt3 that wasn't quite clear from your question. Maybe increasing the SWD clock might help, as it might get the connection before the target switches to output. But I've accidentally set the SWD pins to output and wasn't able to get a connection to my target and only using the BOOT0 I was able to recover it, if you tied them to ground directly (without a resistor) this will et tough. \$\endgroup\$
    – Arsenal
    Commented Dec 9, 2015 at 7:33
  • 1
    \$\begingroup\$ I finally managed to erase the chip! With ST-Link Utility - I pressed reset button, clicked "full erase" and release button and it somehow erased itself and now it works. I tried that before but only now it worked. \$\endgroup\$
    – zupazt3
    Commented Dec 9, 2015 at 20:03
5
\$\begingroup\$

if you're using stmcubemx, u need to configure the serial wire on stmcube pinout tab. on pinout tab, click SYS and change debug option to serial wire. it fix my problem, and maybe your problem too.

\$\endgroup\$
2
  • \$\begingroup\$ While that could be an issue, If leaving SWD pins in the power-on default of SWD mode is not the default setting of this software suite, that's arguably a fairly severe usability defect that needs a bug report and correction. Are you sure you didn't change the settings from their original values, or start with a particular project that required using those pins in a non-default way? \$\endgroup\$
    – Chris Stratton
    Commented Mar 18, 2017 at 18:07
  • 1
    \$\begingroup\$ I firstly just set my pins as SYS_SW.... but they colored in orange. Also had problem connecting to chip after uploading the code. When I selected debug mode in SYS-Serial Wire, the chip connects normally after flasing. \$\endgroup\$
    – gtu
    Commented Mar 18, 2020 at 19:26
1
\$\begingroup\$

I downloaded some code to my own STM32F427 board. Then I can not connect to my board using ST-LINK Utility anymore. I think my code messup the debug port pin configurations(? can not confirm). What I did is the following to make the connection and reprogram my board:

  1. Open the ST-LINK Utility and get ready to "Connect" in the Target menu.
  2. Power your board(in my case, I use a USB cable) and AT THE SAME TIME click the "Connect" from the ST-LINK Utility.

I restored 2 boards with this trick. Hope this helps. --Bob

\$\endgroup\$
1
\$\begingroup\$

Like dili said:

if you're using stmcubemx, u need to configure the serial wire on stmcube pinout tab. on pinout tab, click SYS and change debug option to serial wire. it fix my problem, and maybe your problem too.

STM32CubeMx doesn't configure the debug port by default, consequently ST-Link will stop working once you flash your code. You have to erase the chip with ST-link Utility for example. To connect with the MCU I have had to pull the BOOT0 pin high during power up to activate the bootloader. Then go to Tarjet menu and Erase chip.

\$\endgroup\$
1
  • \$\begingroup\$ To configure the debug pins automatically in STM32Cube IDE, go to the Pinout & configuration tab > System core category > SYS > Select "Serial wire" for Debug. Flashing and debugging worked for me afterwards. \$\endgroup\$
    – Nicolas
    Commented Mar 21, 2021 at 16:01
1
\$\begingroup\$

Ran into the same problem on STM32F1xx. Specifically I couldn't connect to the STM32 chip using SWD interface on my custom board, while everything worked fine on STM32F7xx running the same firmware on a NUCLEO board. In my case, there were 2 reasons for this:

  1. the startup code (generated by the SDK and CubeIDE) disables the SWD interface almost immediately after the power-up UNLESS you specify that you're using SWD in the .ioc file (the pinout and configuration view in STM32CubeIDE)
  2. it wouldn't have mattered if the nRST line was routed to the SWD interface on my board. Alas, I forgot to bring it there.

Short-term solution: brought the nRST signal from the programmer to the reset line using the external wire (in my case it was easy, since I had a physical reset button on my board). Then flashed it with the FW version had SWD specified in the pinout view. After that, there was no need to connect the nRST anymore.

Long-term solution: route the nRST line to the SWD interface in the next revision of the board. With this change, I could safely disable SWD during startup and repurpose the pins

\$\endgroup\$
1
  • \$\begingroup\$ These points were all made by others a number of years ago, so it's not really clear what this posting adds to the page. \$\endgroup\$
    – Chris Stratton
    Commented Dec 15, 2020 at 2:57
0
\$\begingroup\$

To re-program the MCU, hold the reset button and choose connect to device in ST-Link Utility or press download in your IDE (for example Keil) and then release reset button.

\$\endgroup\$
0
-1
\$\begingroup\$

The boot pins (bits in some versions) can prevent the debugger from starting. Make sure you do not implement the boot pattern on startup (certain binary pattern on the boot0 and boot1 pins), otherwise your MCU will get into boot state.

\$\endgroup\$
2
  • \$\begingroup\$ I got boot0 pin tied to GND... I am not sure about what you have written, because - as I said - I managed to successfully program my flash and the program still executes itself on MCU - I just cannot connect to MCU with ST-Link over SWD interface. Under reset it shouldn't execute booting and pins should be in default state so I don't understand why it doesn't connect. \$\endgroup\$
    – zupazt3
    Commented Dec 8, 2015 at 13:57
  • \$\begingroup\$ Are you sure about that? What combination do you believe would disable the SWD in a way which manipulation of the reset cannot override? \$\endgroup\$
    – Chris Stratton
    Commented Dec 11, 2015 at 2:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.