Electronic – STM32L031G6 Power on Reset Issue

brownoutpower supplystm32

I currently have a PCB that I designed using a STM32L031G6 MCU. I have designed many boards with STM32 chips as well as other MCU's. Typically I have a simple cap and pullup resistor on the RST line to help with power on reset and/or brownout. I have never had an issue before this board.

I have two of these made, as they communicate together. One is powered from a 3v3 benchtop supply, the other from 3V from AA batteries. Both of them will only start properly around 10-20% of the time. I have to power cycle many times to get it to finally start correctly. If I reset or program it from my STLink, it starts perfect every time.

I know I can use a POR supervisor and that should fix it, but it is surprising to me that in 10+ designs I have had with STM32 chips, it has never been an issue. It's also tough because this is a low cost design, and we really don't have the BOM cost for a $0.30+ part..

We have changed the Brownout reset threshold level's using option bytes, and it didn't have a large impact. Also changed C9 to a 10uF and nothing changed either.

Any thoughts?enter image description here

Best Answer

Within the limits explained in comments on the question, here is some analysis.

(Note: From your earlier comment that the boards "communicate over a spi - > rf chip", I believe that the boards have no direct electrical connection between them, and only use an RF link. If that is not correct and if the two MCU are actually directly connected, then additional points from another answer become possible too.)

Both of them will only start properly around 10-20% of the time.

  1. If C10 and C11 (2 x 0.1uF) are the only power decoupling, that is insufficient. See the "STM32L0 Getting Started" document for more details. I have seen situations where boards with inadequate decoupling work correctly only with a JTAG debugger attached, because the debugger adds additional decoupling on the power rails, allowing the target board to then work.

    If there is extra power rail decoupling on your board (not shown on the public snippet of the schematic) which meets the requirements and physical placement shown in that document, then continue to the next point.

  2. No external pull-up resistor is needed on NRST. What happens if you remove it?

  3. NRST can be driven low by the MCU itself. When the MCU fails to start on your boards, is NRST being driven low by the MCU?

  4. I know I can use a POR supervisor and that should fix it

    Have you tried adding a POR supervisor, to see whether that does actually help to make the start-up reliable, without an STLink attached? If that does help, it would point towards an issue with reset / power rail ramp-up etc.

  5. You mention reset and BOR, but there are other reasons why MCUs can fail to execute their internal code. Therefore the problem may be elsewhere.

    I can't see the full external connections due to the lack of full schematic, but for example, an external device powered from a different voltage source to the MCU can cause startup problems, by forcing MCU pins outside the MCU voltage rails. That's just one example.

    Since there is no previous working prototype, I would suggest going back completely to square one. Take one of the existing boards, disconnect all external active devices (e.g. RF comms IC and anything else connected via SPI) by cutting PCB tracks if necessary, and convert that one board to become a minimal test board, just with decoupling capacitors. Add just one LED + resistor (if it doesn't have one) and load a simple "blink LED" firmware.

    Does that start and blink the LED reliably, without any STLink attached?

    • No? That's unfortunate, but you have just simplified your "problem space" significantly. Review the "STM32L0 Getting Started" document for the minimal requirements. There should be no places where your (now-minimal) board differs from the minimal setup shown there.

    • Yes? Then you now know that the MCU start-up was being affected not by reset, but by something external to the MCU on your board (something which you have disconnected). You can now investigate those areas (not shown on the public snippet of the schematic).