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'sI'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.

[John F.]

Posted on May 03, 2013 at 12:11

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

[russdx]

Posted on May 03, 2013 at 12:31

Soldering is all done using paste/oven, quality is very good, so I don't think this is the problem.

Checked the one 3.3v reg with my scope and its a nice perfect smooth 3.3v.I'm really hoping its these load caps as its a relatively easy fix!Thanks for all your input guys, Any other ideas welcome :)

[russdx]

Posted on May 03, 2013 at 16:35

Replaced the load caps with known good ones from previous batch, NOTHING still remains in this using internal oscillator state.

I got a feeling what ever is happening is damaging the stm32f4s.Or i have a batch of faulty stm32f4'sNext step is to swap some caps on some other boards before I turn them on!

[jj2]

Posted on May 03, 2013 at 16:48

Never stated - have you retained 2,3 original, ''Golden Boards?''

How do you ''really'' know that the software you've recently loaded - is exactly the same as that used in the past?  Again - this highlights the value of retaining golden boards. Should not you create very small, basic program - which toggles several Leds @ known rate - and load then observe that?  Advantage here is that SW can then be removed from ''suspect'' list.  Our group has bank of special test fixtures - always run every board first thru this fundamental screening - prior to loading ''real/production'' software. It may not be as simple as you think to confirm xtal oscillation.  Without well buffered hi-Z probe - you may sufficiently alter the xtal osc. circuitry - thus confounding any measurement/verification. Wise to measure the current draw of old vs new.  And while 3V3 seems good - have you looked intently @ power-start-up conditions?  Spike, poor rise-time here may be the culprit - and would not fully reveal w/more ''casual'' 3V3 regulator measure...

[russdx]

Posted on May 03, 2013 at 16:57

I have one know good board from previous batch im using as a comparison.

The firmware is the exact same .dfu file loaded onto the previous batch so im 100 positive its the same software.Very confused.

[Tesla DeLorean]

Posted on May 03, 2013 at 16:57

Can you check the crystal pins for shorts, or xray the board?

Rather than pushing on a primary code load, step back and attack the problem from a software/hardware perspective. Just build a simple validation app, that brings up the HSE/PLL and uses GPIO/LED to indicate phases of initialization and success/failure. May be put in a loop that repeatedly turns HSE off/on and waits to let it come ready. If HSE isn't starting you need to look carefully along all the signal paths from the chip, to the crystal, to the resistors and capacitors. Output internal clocks via MCOx pins, measure.

[jj2]

Posted on May 03, 2013 at 17:23

Earlier: ''Should not you create very small, basic program - which toggles several Leds @ known rate - and load then observe that?''

And: ''Just build a simple validation app, that brings up the HSE/PLL and uses GPIO/LED to indicate phases of initialization and success/failure.'' That's 2 votes now for an improved basic SW/HW Sanity Check... Dawns now that ''programming procedure/equipment'' may have varied.  (even slightly)  As always - we prefer ''real/proper'' pull-up Rs on all JTAG lines...

[russdx]

Posted on May 03, 2013 at 17:46

My problem is, I only have the USB interface, no uart or other programming interfaces exposed.

But the usb dfu mode does not work correctly when the chip is in this slow mode. Pc just says unknown device.I have no way to load test programs onto it.Maybe i should try and solder on to wires to rx/tx and load some firmware using uart?

[emalund]

Posted on May 03, 2013 at 18:00

my guess is that your layout is not ''tolerance tolerant''

e.g. are the connections to crystal, burden caps, decoupling caps less than 5mm? if the above is not adhered to, you become suspect to component tolerances such as a slightly different behavior (well within the tolerances in the datasheet) of a capacitor.   as an example I once solved a problem someone had by soldering a decoupling cap directly across a chip. the customers guy cried ''I have a decoupling cap there and the last 500 boards worked fine'', but a trace of 3cm was enough to make the decoupling ineffective.

[jj2]

Posted on May 03, 2013 at 20:28

''my guess is that your layout is not ''tolerance tolerant.''  Bloody true that - these fine geometry devices are not especially forgiving...  (btw - ''tolerance tolerant'' rolls off the tongue - much like ''unknown & known unknowns''... D. Rumsfeld)

You've clearly saved the 0.10 USD cost of JTAG R's, pads for programming ''bed of nails.''  And made yourself vulnerable to any/all ''less direct'' means of programming/debugging.   If it were me - I'd ''harvest'' some of your past profits from 200 pc earlier sale (one hopes) and acquire Olimex or better JTAG probe.  Then add pull-up Rs to small adapter board - and find shortest signal path means to attach these to JTAG.  (while complying w/Erik's advice - up one) Bad design choices ''up front'' have come back - and now haunt.  Most all serious/pro boards expose JTAG - to escape such traps...