STM32F407 clock problem? on production boards.

[russdx]

Posted on May 02, 2013 at 23:24

Hello

I have a production board that I have currently produced 200 Units, the board uses a STM32F407VET6 and all 200 units work great!

I have just had another batch made up. I have tested 3 so far and 2 have died after 5min! They don't totally die but seem to stop using the external 8mhz crystal and use the internal oscillator, as I have put a scope on the external crystal and its dead.

The two 'dead' ones now seem to run the firmware at like a 3rd of the normal speed. To the point the DFU does not work any more. So I can not connect them to the pc to load new firmware on.

I'm not sure what has gone wrong on these boards? I did notice I used a different load capacitor for these new 200 boards to the previous ones. Could this upset the clock to a point it stops working? If so how come it works for a bit then dies? And when it dies it stays dead. No matter how many times I power cycle it, it remains in this 3rd speed mode.

Have these new load caps damaged the stm32 chip? Or have a received a dodgy batch of stm32's

I'm really confused to why my boards are dying and am not really sure what direction to go in to repair them?

Any help would be really appreciated.

[dthedens23]

Posted on May 03, 2013 at 00:19

Occam's Razor

Whatever you changed has made the boards fail and the seem to be using the internal oscillator.

[Tesla DeLorean]

Posted on May 03, 2013 at 00:32

The HSE does not turn on automatically, so code in SystemInit() or wherever needs to enable it and traverse the settings, pll, lock time, and deal (or not) with errors and failures.

The difference between the 8 MHz HSE, 16 MHz HSI may not be accounted for in the hard coded PLL settings, this in itself may result in odd behaviour. ie out of spec comparison frequency, or VCO frequency.

I guess I'd be trying the BOOTx pins, dumping validation software in via JTAG/SWD or system loader, and evaluating why the HSE fails to start, or stops.

Better coding in SystemInit() may permit more effective failover performance.

How the oscillator functions will likely depend on the cut, and characteristics, along with those of external components. Not sure any of this would fatally kill the STM32. Do things work if you substitute back the originally spec'd components?

[waclawek.jan]

Posted on May 03, 2013 at 06:34

Working out of my crystal ball, but I bet you used a high-speed crystal (24 or 25MHz) and in the new batch you purchased crystals intended for 3rd harmonic use.

As Clive said, try to pull a crystal from the old batch and put it into the new one.

JW

[jj2]

Posted on May 03, 2013 at 07:08

Assumption here is that you made/retained 2-3 ''Golden Boards'' - which enable such ''A-B'' testing.  (and - if you did not - you know now why this is, ''normal/customary.'')

Along w/transferring old board parts to new - reverse is equally of value. 

Xtal remains primary suspect (per Jan's 3rd harmonic ''get'') but measure/swap xtal bypass caps - too high a value may wreak havoc.  MCU reset circuit - lowly 3V3 regulator - and even power supply to dut/but (board under test) must be test/verified as well.

[russdx]

Posted on May 03, 2013 at 07:15

Thanks for all your replys

The only parts that have changed between batches are the 2 load caps on the crystal and the 4.7uf cap on the 3.3reg has gone from a 16v to a 10v.

The load caps are a totally different manufacture now. The crystal and all other components are the same as the first batch.

When i say the boards are 'dead' they are not dead but just running very slow, and using a scope i can see they are not using the external crystal. it seams when they die they stop using the crystal. but i would of through after a power cycle they would come back to life for a bit then die again. but they just stay in this slow mode.

Im going to swap out the load caps on the crystal today with some left overs from the first batch see if it will come back to life.

When they go into this slow mode and stop using the external crystal has some thing been damaged? or should replacing the load caps make them happy again?

[John F.]

Posted on May 03, 2013 at 09:16

Check the new capacitors are the value you expect. Also maybe have a look at AN2867 Application note Oscillator design guide for STM8S, STM8A and STM32F1 microcontrollers (Yes, I know it says STM32F1 and you have an F4).

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00221665.pdf

[russdx]

Posted on May 03, 2013 at 10:24

Thats a good read thanks.

My first step will to be replace the crystal and load caps on a dead board with another crystal and the original load caps.

See if the stm32 comes back to life. If not ill have to assume its some how been damaged by the load caps/crystal.

Can a stm32 be damaged by a bad crystal/load caps or a badly set up oscillator circuit?

[John F.]

Posted on May 03, 2013 at 11:33

''Can a stm32 be damaged by a bad crystal/load caps or a badly set up oscillator circuit?'' No. It just doesn't oscillate. If you haven't changed your PCB layout since it previously worked then it's most likely to component problems. Wrong types or values for example as others have suggested. If it STILL doesn't work even with the original components, then you've unwittingly changed something - time to find out what!

[russdx]

Posted on May 03, 2013 at 11:44

Same firmware.

Same pcb gerbers

Same components (apart from load caps, 4.7uf cap)

It must be these crystal load caps, Cant wait to swap them over when I get home.

What I find confusing is when I first plugged the boards in they worked great, then stopped using the crystal and no matter how many times I power cycle them they don't come back to life properly. I would of thought after a power cycle it would come alive again for a while then die again.

[John F.]

Posted on May 03, 2013 at 12:11

Poor soldering / footprint? Power Supply problems? Current limit mistakenly set too low? Something!