Fried my board?

[gsantha]

Posted on December 01, 2011 at 21:21

Hi!

I hooked up an 2x16 LCD display with backlight to the board's EXT_3V pin and GND. (The display is a 3V type: both logic and backlight, so not the typical 5V one). I didn't experience any trouble, the USB didn't disconnect indicating high current etc. The display had lit up and one line of blocks showed up - that's the expected behaviour. A few minutes later I disconnected the board from my laptop. An hour had gone with coding and I wanted to download my code so connected it. It gave me an error message box: Fatal error: ST-Link, No MCU Device found. Session aborted! After pressing OK another message box appeared indicating that the flash loader was failed. I dis/reconnected the board, restarted IAR, restarted Windows with of no avail. The strange thing that the MCU is seems to be working - my last code is running, flashing the LEDs in every 5s as I was experimenting with RTC alarm interrupt. I checked the voltages and they are correct. Checked the U1 LDO and it has the correct output voltage of 3.3V which is forwarded by D1 Schottky with the loss of ~0.3V - OK. The red LED is lit, the dual colour LED is also working, it is red. The jumpers are OK too. Measured the MCO output with freq counter at SB17 and had 8 MHz readout. No idea. Is it the  U2 (STM32F103C8T6) which is corrupted? I can't imagine how since it has a normal 8MHz output clock. Or the main MCU? It seems to be up and running with a fairly complex code. I just ordered a new one anyway, but would like to know if it can be repaired so I'd thank any idea... #metoo

[Tesla DeLorean]

Posted on December 02, 2011 at 04:45

One of the classic tricks with the ST-LINK when it can't wrestle control of the target CPU is to reboot the chip with the BOOT0 pin pulled HIGH, this sends it to the system ROM instead of the user application code.

[gsantha]

Posted on December 02, 2011 at 09:59

Hi clive1,

did you mean pulling up BOOT0 at STM32F103C8T6 (U2)

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00027954.pdf

?

[gsantha]

Posted on December 02, 2011 at 15:10

Never mind, just solved the problem. Thanks for the tip, clive1.

In case somebody is in the same shoes: 1. Locate SB3 bridge on the board, close to the ST logo. It is bridged by a small, 0402 0 Ohm resistor. Remove it. 2. Get a common, 2.54mm right angle pin header and break a 2 pin piece off. Shorten the pins and solder each pin to each SB3 bridge pads. Be sure that you don't short the bridge with solder. 3. Now you've got an 'enhanced' bridge. Close it with a common jumper. 4. Next time your code 'bricks' the chip just remove the jumper, replug the board, download a proven working code. 5. Unplug the board, close SB3 with the jumper again and replug the board, thats all.

[Tesla DeLorean]

Posted on December 03, 2011 at 04:21

Sorry, I should have been more explicit, the BOOT0 pin on the target STM32L152 (or STM32F100 on the VL Board) part, that would otherwise be running errant code.

The problem typically occurs with DMA unit(s) generating bus traffic independent of the core as the JTAG tries to wrestle the process to a stop. That or some problematic code that executes very soon after reset. BOOT0 High causes the processor to enter the System Loader, which is more of a ''safe harbour'', from which the JTAG has a clear shot at gaining control.

[gsantha]

Posted on December 03, 2011 at 08:33

Exactly. To connect my LCD's data bus, I configured the PA13 pin (among others) as an output pin. This initialisation happened early in my code thus rendered the JTAG pin unreachable - at least I think.

[rj]

Posted on February 11, 2012 at 23:49Hi. I think I ran into the same problem you had. Did you ever figure what caused it to hang up? Im trying to debug what going with my board, and our problems seem identical. Thanks-Rio

[Tesla DeLorean]

Posted on February 12, 2012 at 01:44

I think I ran into the same problem you had. Did you ever figure what caused it to hang up? Im trying to debug what going with my board, and our problems seem identical.

If they are identical the content of the thread should be sufficient to resolve the situation. I think if you read through to the end Greg73 stated he was reconfiguring some pins, and in doing so blocked access by the debugger. I've stated a number of other conditions that cause this, but they are legion, as the ST-LINK is not very effective in handling corner conditions. For the issue with errant code the method I have offered is quite effective, but clearly if you have really fried the board there is not much you can do but start replacing parts.

[vinniesletterbox]

Posted on February 21, 2013 at 13:26

Hi Greg,

Have similar problem, just started using the stm32f0 discovery board. Have this error in my log screen... Fatal error: ST-Link, No MCU device found. Previous program seems to be working fine?? Any help would be great. Regards.

[Tesla DeLorean]

Posted on February 22, 2013 at 01:28

Awesome, did any of the suggested remedies work, not work, whatever?