search

japaric / stm32f103xx-hal

HAL for the STM32F103xx family of microcontrollers
Apache License 2.0
116 stars 40 forks source link

blinky program bricked Blue-pill #20

Closed HemantJoshi closed 7 years ago

HemantJoshi commented 7 years ago

Even though I could flash and run the program successfully, however when I decided to reflash, I couldn't even connect to the device via ST-Link. The device was found bricked. Although I could restore it, there is some problem with the program some where. Such a problem is typically caused by program/app unintentionally writes to SWD signals. Hence the MCU can't respond ST-Link. Or some other problem that is causing SWD function breakdown. Note that I didn't alter the blinky app or source any where. And tried a few times on multiple bluepill boards. The program works fine. However the problem is noticed when you try to debug or connect using ST-Link or J-Link.

protomors commented 7 years ago

In this example between interrupts processor is put into low power mode using wfi instruction. It could interfere with debugging. The best way to deal with it - is to connect under reset (in my experience OpenOCD sometimes has problems with this). Try to use ST-Link utility from STM and in target setting select "connect under reset". Does it successfully connects to "bricked" boards?

HemantJoshi commented 7 years ago

I had already tried protomors' following (in the quote) suggestion. But still I couldn't connect to the bricked board. "Try to use ST-Link utility from STM and in target setting select "connect under reset". Does it successfully connects to "bricked" boards?"

In order to at least narrow down the problem, I tried hello program. This not only worked correctly, but didn't brick the board either. So what is the difference between hello and blinky. Both call wfi in idle. So the difference at high level are,

  1. driving a gpio and use of timer in blinky
  2. Use of embedded-hal

A broad inference may be that the hello program, as I see, uses only generic functionality of the cortex-m and not of any specific device. And hence the generic functionality works for stm32f103 as well.

HemantJoshi commented 7 years ago

I found a work around so that I continue my exploration. I made a hard-reset (by pressing the reset button on the board). And while the the MCU is still in reset, I could easily connect via openocd + ST-Link. ST also recommends to "connect under reset".

The issue that I faced has two angles:

  1. The issue doesn't happen with all apps. For example when do mbed development, I never faced this problem.
  2. There might be issue some where else.
  3. Since I found a work around and the issue is not holding me back, I am closing the issue.

.

protomors commented 7 years ago

I made a hard-reset (by pressing the reset button on the board). And while the the MCU is still in reset, I could easily connect via openocd + ST-Link.

Yes, I was talking about hardware reset. There are some situations when microcontroller does not respond to reset command through SWD (stuck in the whi or SWD pins configured for something else). This is why I always connect RESET pin from ST-Link to microcontroller and setup debugger to use it for connecting (by default openocd uses software reset). Then there is no need to press reset button on the device and debugger always connects without problems.