STM32F4 fails to startup

[rubenswerk]

Hello,

I'm running the ChibiOS STM32F4 Discovery Demo without any problems on the original ST Discovery board.

When I try to run the demo on a selfmade board, the startup is not relyable.
Sometimes (50% of my tries), the demo starts correctly and runs for hours without any problems.
But sometimes the code fails to jump into the initialization routine. It doesn't matter if I do a cold or a warm reset.

First I thought it was a problem with the clock, but even if I inject a clean clock signal from an external oscillator, the problem remains (I set the HSE Bypass option in that case).
BOOT0 is tied to GND via 10k. Reset is done via 100nF & 100k. I measure a core voltage of 1.25V at the external capacitors. Vdd is 3.3V.

I only have the ST-LINK Utility as debug possibility. When the software fails to start, it show me:
PC points to _default_exit, but sometimes also to ResetHandler or _unhandled_exception
MSP = 0x20000400
PSP ~ 0x200007c0

My linker options are:
__main_stack_size__ = 0x0400;
__process_stack_size__ = 0x0400;

How can __default_exit() ever be reached? I think it should only be called when returning from main(), but I have an infinite loop in my main function.

Do you have any ideas why the same software on the same board sometimes gets stuck?
Bye, RuWe

[Giovanni]

Hi,

Try running it from HSI, this should rule out HSE clock problems.

Giovanni

[rubenswerk]

Hello Giovanni,

good idea. I removed the crystal and configured the HSI. Same result as before - sometimes it works, sometimes not.
It doesn't seem to be a general stability problem - once the software is running, it's absolutely stable. I can change the supply voltage or ambient temperature without any negative effect...

RuWe

[Giovanni]

Does the reset circuit work correctly? It is possible the front is unstable or too slow.

Giovanni

[rubenswerk]

Hello Giovanni,

I still have no idea what's going wrong here.
What do you mean with "front"?

Leaving the nRST pin and BOOT0 unconnected, leads to the same behaviour. However, if I tie nRST to ground or BOOT0 to Vdd, the software never starts - this is what I expect, so the routing of nRST and BOOT0 is correct.

I tried different R/C combinations for the reset circuit, it makes no difference. Also if I connect it to the Discovery board and SWD takes control of the reset line - no change. I can trigger resets with the ST Link tool - sometimes the software starts, sometimes it fails.

Does the power supply cause my problem? It the basic supply scheme: 3v3 LDO regulator, decoupling capacitors on all Vdd pins, 2 x 2n2 on internal core voltage regulator, supressor coil for analog supply.
The problem remains also in case of a warm reset, where power supply should be stable.
Code flashing & verifying via SWD works 100%.

Do you think it would be helpful to make the Eclipse toolchain running and step through the code? I have no experience on that. Can I set a breakpoint on the reset vector and step through from the very beginning, or does the SWD interface have to be initialized by software (which would probably fail if I want to debug the bad case)?

Bye, RuWe

[Jacon]

2 x 2n2 on internal core voltage regulator

2n2 or 2u2, as it should be ?!

[rubenswerk]

Sorry, wrong typing. I use 2u2. I even tried the original capacitors from the discovery board.

I started to build up one more proto board (happily I ordered several of them).
I only placed the power supply and the STM32 on it, nothing else.
I only soldered the absolutely necessary pins of the micro and left the rest unsoldered. This board worked quite good, I could start it ~50 times in a row before it hung up. So I had an 'error rate' of 2%.

Then I soldered the rest of the pins. Now, the boards has an error rate of 50%.
I see two possibilities:

1.
The tracks on the PCB act as an antenna, capacitor, ... (?) which influences the micro. In my changed ChibiOS demo, all pins are configured as inputs with pullup beside one blinking LED output. There is no peripheral soldered on the board, all tracks have an open end.

2.
The die temperature was too hot during solderung and there is a thermal damage in the processor. I use a Weller PU81 soldering station set to 425°C. I usually solder one side of the micro, which takes only a few seconds. Then I wait for about a minute to cool down again. Up to now I couldn't find the official soldering recommendations, I'll have to search ST's site.

Maybe it's worth a try to unsolder the processor and put it on the discovery board to see if the strange behaviour remains. Never tried to re-solder a 100pin TQFP

Bye, RuWe

[Giovanni]

Weird, does your PCB have a continuous ground plane layer?

[rubenswerk]

Yes, it's a double layer PCB. The bottom layer has a lot of GND, not so many tracks there. The top layer is also flooded with a GND, but there are a lot of tracks, so the GND areas are quite small.

In ST's application note AN2639 they describe different soldering methods. The reflow preheat temperature is <=217°C. Unfortunately, they do not mention the soldering temperature. They say that the peak/classification temperature "is indicated on box label", whatever this means. I was unable to find out this value.

On page 4 they mention that "the whole package body is exposed to a very high temperature (> 240 °C) during reflow soldering process". If they call 240°C a very high temperature, how about the 425°C of my soldering iron?

I chose this high temperature, because with my very thin soldering iron tip I have problems to heat up bigger components. I don't know what's the actual temperature at the micro if I put the analog temperature knob to 425°C. I think it's not very precise, but probably >240°C.

[Giovanni]

Some months ago Barthess was sent an F4 unsoldered from a discovery board and then he manually soldered it again on his custom board, I don't think temperature is such a big issue, the component would be more likely destroyed.