1
\$\begingroup\$

Background: 1.5% of products which use STM32F107 didn't work after using 3 months; Lithium battery is the power supply source. The products were used in car. This phenomenon suddenly occured without any pridication. According the record in product, the temperature is normal(25 Centigrade).

Problem Analysis: The voltage at VDD is 3.3V. The NRST reset do not work. After disconnecting the power and connecting again, the chip could recover and work again. And this problem could not be reproduced in our lab condition.

Additional information: the chip use STANDBY mode to shut down and use WAKE UP pin back to work.

The schematic is attached below.(Only the core components displayed)

Is the schematic wrong or did I missed something? schematic picture

\$\endgroup\$
  • 4
    \$\begingroup\$ "1.5% of products which use STM32F107 totally dead" and "After disconnecting the power and connecting again, the chip could recover and work again." - Together, those statements cannot both be true, The chip cannot be "dead" if a power-cycle restores operation. :-) IMHO you need to better define "dead", to help your investigation focus on possible causes. "The NRST reset do not work." - How did you prove that? Perhaps the chip did reset fine, but then immediately hangs for another reason? The lack of decoupling capacitors on the schematic is a concern, for example. Overall, more data needed. \$\endgroup\$ – SamGibson Oct 22 '16 at 8:01
  • 1
    \$\begingroup\$ "Only core component displayed". Depending on what you mean by "core" you may hide information that is critical for debugging the circuit. Please post a complete schematic, or at least the complete schematic of the MCU board. \$\endgroup\$ – Lorenzo Donati Oct 22 '16 at 8:12
  • 1
    \$\begingroup\$ BTW, we need additional information about the environment where the product is deployed and the product itself. The fact that you cannot reproduce the fault in lab environment is a strong hint that there is something wrong with how the product is deployed on the field. Wild guessing: installation procedure is wrong; insufficient protection against interference or ESD; the product must be used by unskilled personnel and it is not "idiotproof", etc. \$\endgroup\$ – Lorenzo Donati Oct 22 '16 at 8:16
  • 1
    \$\begingroup\$ A clearer description of the problem will help a lot. Assuming an extrapolated failure rate in hours, its no surprise you can't re-create - but that is step 1. ESD, EMC, temperature, PSU, firmware are possibilities. Try running on low/high supply tollerances, at temp extreme to recreate the issue in the lab. \$\endgroup\$ – Sean Houlihane Oct 22 '16 at 9:19
  • 2
    \$\begingroup\$ m.littelfuse.com/~/media/electronics_technical/… and ti.com/lit/an/snva681a/snva681a.pdf show the very worst that automotive electrical enviroment can throw at a device. I suspect your getting latchup... test with these values to see if it is being damaged. \$\endgroup\$ – Spoon Oct 22 '16 at 10:50
3
\$\begingroup\$

As I said in my comment, I'm not convinced that the true "failure mode" has been defined - "dead" does not appear correct.

However I have found one error in the design, from the excerpt of the schematic supplied - \$\small V_{BAT}\$ is not connected. I'm checking the docs now, but I believe that is required. From memory, failure to reset properly is one possible side-effect. More to follow...


Update: From the STM32F107 reference manual, they say it is "recommended" that \$\small V_{BAT}\$ is connected to \$\small V_{DD}\$ (and decoupled). I seem to remember rare reset-related issues without this connection, but I'm away from my notes so don't have more details.

STM32F107 reference manual section 5.1.2

The same advice is given in Application Note AN2586 - Getting started with STM32F10xxx hardware development:

AN2586 - Getting started with STM32F10xxx hardware development

I'm not convinced about the analog filter in the schematic, as Marko has mentioned and, as Lorenzo has said, not being able to reproduce your problem in the lab is telling you something. Something is different (e.g. power quality, user behaviour, EMI, shielding etc.) between your lab test procedure and/or your lab environment, and the environment where the units "fail" (in whatever way that "failure" is eventually defined).

One more thing: Your external components attached to nRST don't match the recommended configuration by ST (you've got an external pull-up resistor which they don't recommend). I am not saying that this is causing a problem - just that it may need further review.

However I have run out of time for now. Hope this info helps.

\$\endgroup\$
  • \$\begingroup\$ Thanks a lot. The "dead" indicates no responding any acts including the reset pulse on nRST and the chip could recover to work after a power cycle. I will check datasheet and find out more difference. \$\endgroup\$ – wilyas Oct 22 '16 at 10:03
  • \$\begingroup\$ @wilyas - Hi - "no responding any acts including the reset pulse on nRST and the chip could recover to work after a power cycle" - I wouldn't call that "dead" (perhaps this is a translation issue); instead it could be described as "non-responsive". Your schematic doesn't show a reset button, so it isn't clear how you caused nRST. Anyway, assuming you triggered it by hardware (jumper wire?) then lack of response is either that nRST did happen, but code immediately stopped/hangs etc.; or hardware is in a very strange state (latchup?). \$\endgroup\$ – SamGibson Oct 22 '16 at 10:18
  • \$\begingroup\$ I short the capacitor C24 to generate RESET PULSE.In my code, the chip would initialize the external crystal to use HSE as soon as main function called, but now there is no signal on crystal pin. According IO signal detected, the chip acts just like always in reset state. I believe that the chip was in latch up. \$\endgroup\$ – wilyas Oct 22 '16 at 10:48
  • \$\begingroup\$ @wilyas - Yes, your comment fits with my hypothesis of latch-up (or similar). However it would need much more info about the device inc. full schematic, photos, PCB layout, wiring layout, more info about power etc. for me to be able to add more suggestions. I see your update that power is from a "Lithium" (really Li-Ion?) battery - but there are missing details e.g. you are charging the battery from somewhere :-) I realise you may not want to disclose all that info, but then you won't get the best answers. More info also needed on exact timeline of events, before "failure" is discovered. \$\endgroup\$ – SamGibson Oct 22 '16 at 17:08
1
\$\begingroup\$

Your filter for analog reference is wronk, see datasheet. VDA and Vref+, as well VSA and Vref- are internaly conencted. Also Vref- should be at GND level.
If the pushbutton is located outside and you wanted to protect the input with TVS, IMO you didn't made a perfect thing. You could enable puull-up resitor in MCU and avoid using an external pull-up, in such situaiton the ESD discharge goes directly on the MCU 3.3V trough a resitor.

\$\endgroup\$
  • \$\begingroup\$ VDDA and Vref+ are internally connect only on 64-pin package.Your opinions about analog reference and the ESD would be helpful. \$\endgroup\$ – wilyas Oct 22 '16 at 11:24
  • \$\begingroup\$ @wilyas You'd better install one additional series resistor and small parallel capacitor after the TVS. Only then you can connect the pull-up resitor. It will help to limit the dV/dt and thus delay the signal before the TVS starts conducting. \$\endgroup\$ – Marko Buršič Oct 22 '16 at 11:27
0
\$\begingroup\$

Not that this will be much use to the question asker now but for those having the same problem try pulling the BOOT0 pin low with an external pull down resistor.

If BOOT0 is high then the micro will assume that the flash is blank, enable peripherals and wait for instructions. By pulling it low you ensure that it will always check for user code in flash on startup.

There is almost certainly some work around for this in software but hey, resistors are cheap.

\$\endgroup\$
  • 1
    \$\begingroup\$ Welcome to the site :-) Your recommendation for BOOT0 being pulled-down by default, seems to be done already. Unless the pins at "ISP Header 3" are shorted, then BOOT0 is pulled-down via R47 and R65 isn't it? \$\endgroup\$ – SamGibson Nov 4 '18 at 23:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.