STM32F4 not fully programable

Lukasz Przenioslo · ‎2016-09-19

Posted on September 19, 2016 at 12:42

Hello there,

I have a problem with programming STM32F4 device. My Jlink probe correctly sees the device over SWD but it cannot erase nor program it however- This is the Jlink command prompt when trying to erase:

https://pastebin.com/6S4KKFAZ

Some facts about the enviroment that might help resolve the issue:

- I am able to program the same MCU on a different board with the same code.

- I am able to connect with the device using Segger Jlink device, but I am not able to erase or program.

- The device stopped working after about 2 h of proper work. The program stopped and I reset the power. After that I have the current problem...

- I have checked the voltage on the device (it is also visible in the Jlink command prompts) and it is within proper range.

- I have resoldered another STM32F407 MCU to make sure the MCU is not broken.

What could be the case of this situation? If this might be hardware related, what could be the case? I believe that if the ribbon cable connecting the board with the debbuger was faulty, I wouldnt be able to connect at all?

I would really appreciate all help, I am getting out of ideas...

Tesla DeLorean · ‎2016-09-19

Posted on September 19, 2016 at 15:54

The Flash uses a charge-pump to get a much higher programming voltage, the static voltage on the input is a lot less interesting than the dynamic voltage. Review also the voltage on VCAP pins along with appropriate capacitors. Capacitors on the regulator will also impact dynamic performance.

Does the interface include NRST? Does the behaviour change with BOOT0 pulled High? Can you use the System Loader via USART? What error does an ST-LINK and Utilities provide?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Lukasz Przenioslo · ‎2016-09-19

Posted on September 19, 2016 at 16:00

Hi, thank you for answer.

I will resolder new VCAPS (using 2.2uF 0805 ceramic caps) and let you know. I am not sure however if I will be able to measure dynamic voltage on them, would have to solder some wires on them and use scope. Or is there another way?

My SWD interface uses 5 wires:

VREF

GND

NRST

SWDIO

SWCLK

I didnt try with BOOT0 pulled high, it is pulled low all the time. Will check that as well. Also I will have to figure out either I have the proper UART pulled out of the board for using system memory bootloader.

This is the debugger output when trying to debug with Jlink:

https://pastebin.com/zYvPas68

Lukasz Przenioslo · ‎2016-09-19

Posted on September 19, 2016 at 16:14

So far I have replaced the 2 VCAP's to 10uF/25V ceramic ones. I added some more capacitance to make sure its enough for the pump. This havent helped a bit however :(. I will try with boot0 tommorow morning as for today I cant do this anymore...

Tesla DeLorean · ‎2016-09-19

Posted on September 19, 2016 at 17:37

Not sure you need 10uF on the VCAPs, you want bulk capacitance on the regulator side of your design.

The logs suggest it can erase/write the flash, and it dies quite deep into things. Are you sure you don't have anything early in your boot path that snaggles up the flash wait-states or prefetch? Look at if behaviour changes if you just let it run from the 16 MHz HSI and not change that.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Lukasz Przenioslo · ‎2016-09-19

Posted on September 19, 2016 at 19:26

I also tried adding even more bulk capacitance to the regulator output, that didnt help as well. For the pump caps more wont hurt as well I believe. The most peculiar thing is that:

- This very same code works on my other board,

- This code used to work

on this board as well

, it suddently decided to stop and I have no idea why, I did no changes in the hardware.

I checked all the VCC and GND connections, they are still in tact. I will try to run the code at 16 Mhz without pll tommorow morning.

But apart from this code, please keep in mind that I cannot erase the MCU at all. I can erase it using ST link and after doing that, still cannot with JLink. Reasumming:

- Can erase with ST-Link, cant with JLink

- Can program with ST-Link, but code doesnt run. Cannot program with JLink.

- MCU is recognised correctly with both debuggers.

Tesla DeLorean · ‎2016-09-19

Posted on September 19, 2016 at 19:48

Not sure I can explain the failure.

You should be able to validate the image using ST-LINK. If the code is exactly the same, then you need to review the ''does not run'' a bit more. In most cases thing do run, but perhaps run the code different or get stuck in loops before main(). Therefore you'd need to instrument very early in ResetHandler to determine just how deep it gets. Make sure BOOT0 is pulled LOW for your code to run, don't rely on internals or assumptions. Make sure NRST goes high, and is not actively driven externally.

The J-LINK might need newer drivers/firmware, very odd that ST-LINK is viable, and J-LINK isn't, but again there are dozens to options to configure connection/reset methods.

Look at other components, like external clock sources, etc.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Lukasz Przenioslo · ‎2016-09-19

Posted on September 19, 2016 at 20:00

Boot0 used to be pulled low with weak resistor, now I changed it so the pulldown is very strong.

Reset line is pulled up with 10k resistor.

Tommorow morning (I dont have the board with me at home) I will try to reduce the main.c code to see either I can run anything, but again- Using JLink I cannot erase the device, even though it was erased before with ST-Link (memory verified, all 0xFF's).

So There is an empty STM32F4 chip and for some reason JLink cannot erase nor program it, because it cannot acces the ram as I showed in the first post. This gets me the most.

Ps: Also I updated my jlink software today, it also did not help. It feels very much like a hardware problem but I dont know what could cause this really.

adawang150 · ‎2016-09-19

Posted on September 20, 2016 at 04:34

I'm a newbie in Electronics. Nowadays I am trying to learn from your experience.

adam23 · ‎2016-09-20

Posted on September 20, 2016 at 15:09

Not sure how you VREF is connected, but the programmer needs to know the proper voltage from the STM32 to do a proper programming. I did saw a ''broken'' programmer, that was not able to detect the VREF properly and set it incorrectly, leading to various strange errors.

Also keep in mind the ST-Link uses non standard VCC connection to allow supply of STM32 while programming without external power, JLink does not have this to my knowledge, you have to supply the STM32 from external source. Here comes to play the VREF, that has to be detected properly.