EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: jmw on August 21, 2021, 06:29:34 pm
-
I have a microcontroller project board where peripherals occasionally fail or glitch at power-on time. The microcontroller is running (as evidenced by other behavior on the board), but devices it is talking to either errored out or silently failed. I *think* I have traced this to a mechanical issue with the board's DC barrel connector, and I captured some voltage bounce at the main VCC node like this:
(https://i.postimg.cc/XJ62vTrL/scope-3.png)
I can definitely see it on the scope when wiggling the plug when inserting it, but glitching is still maybe 1 in 25 to 1 in 50 events. If I leave the barrel plug inserted on the board, and then plug the adapter into the wall, these voltage drops don't occur, and I have yet to trigger a glitch.
I've taken to inserting a fixed delay at the start of the microcontroller code, under the theory that the peripherals may have reset during the undervoltage event while the microcontroller continued to run. This seems to have worked. Is there anything better I should consider to improve reliability?
-
One thing you can do is to improve your power supply. For example add a relatively big buffer capacitor to bridge your time of the power supply glitches.
Added capacity may cause a problem because of high peak currents when the cable is plugged in though. This may lead to sparks and extra wear on the connector.
Another thing is a "Brown out detector". This is a name for a common circuit that detects short periods of (too) low power supply voltage, and it is by default built in in many microcontrollers. It is most often used to reset the microcontroller during such an event.
Adding a delay at power on as you did is also a good idea. I've built some circuits with both power and RS485 interface though one cable (connector) and each node sent a "Hi" message on power up. I regularly had data corruption of that message until I added that delay.
-
If I read this right it's a 50ms dropout after 150ms? Normally deglitching is handled by holding the CPU in reset, but that's typically on the order of 10ms. If the timing is consistent, then a software 250ms delay on POR seems like a good idea. Assuming a BOR at the wrong time would be bad. Or replace the supply.
-
This is why "power supervisor" ICs are offered by many IC suppliers.
The ON MC34164 is a classic, but there are plenty out there with more features like reset delay etc.
-
Note that if you go off and do a POST on POR without either internal (BOD etc) or external power supervision, then you will likely record spurious hardware faults during POST. Whatever voltage-sensitive peripheral hardware is tested during the dropout, which is likely going to have you tugging at your hair wondering why you have so many units with defective SRAM, or randomly fail to load something/boot from SDIO - always at the same stage?! So, good call on sticking a probe on the rails before proceeding any further.
-
Note that if you go off and do a POST on POR without either internal (BOD etc) or external power supervision, then you will likely record spurious hardware faults during POST.
Everyone loves TLAs, but you've taken it to FLAs as well. Congrats.
-
I'm looking into BOR documentation right now. It appears it is disabled by default on STM32, so I'm going to try enabling it at a level that makes sense for the peripherals and see if that helps. Looking at the datasheets, the STM32 can operate well below some of the other parts, so that points in the direction of my theory that the microcontroller intialized the peripheral, the peripheral reset because of the voltage drop, and the microcontroller continued on with an uninitialized peripheral.
Edit: this is working really well, and seems more elegant than hardcoding a startup delay. Thanks for the info!
-
can you just put a 100ms (or whatever) delay in your bootup code to wait for power to stabilize at the peripherals before initializing them? Could also try to re-initialize them if you find they're returning an error as well.