MCU does not come up after short power-cycle

[LZhan.13]

Hi, we are evaluating STM32L4A6VGT6TR, with our new product prototype. We are only suppling one 3.3V to the MCU as it requires. We have already included discharge circuit, and we can see this 3.3V rail will be completely discharged within 0.288s. However, the MCU cannot every time come up again (loading firmware), if we power cycle within 3 seconds. If we wait for 10 seconds before we turn on the power again, it seems to work OK. We are not sure if we are missing any special requirement regarding power cycle, power sequence about power supply, or critical pins, such as reset. Do you have any inspiration what that could be? Thanks

[Ozone]

> However, the MCU cannot every time come up again (loading firmware), ...

How do you determine that ?
Make sure you connect all BOOT pins to Vcc or GND with pull-up / pull-down resistors to insure a user firmware startup. Else you might inadvertently end up in the ROM bootloader.

[LZhan.13]

MCU does not function as it is supposed to. Fan, LED, etc. don't come up at all. 

Is it only one BOOT pin with this package? We do connect it to gnd with pull-down res. 

[Ozone]

> Is it only one BOOT pin with this package? We do connect it to gnd with pull-down res. 

The more relevant information you give upfront, the more precise the answers are.

Such restart issues are almost impossible to debug directly.
As per recommendations of Tesla deLorean, instrument the startup code, including the clock setup.
Work you way back if you don't see output on the scope.

[Andrew Neil]

Have you instrumented to see what's happening in this "not working" state?

• UART logs?
• LEDs?
• Clocks running?

Can you connect the debugger:

https://community.st.com/t5/stm32-mcus-embedded-software/processor-stuck-if-i-run-code-without-debugger/m-p/802267/highlight/true#M63401 

[Tesla DeLorean]

MCU probably starts, with BOOT0 pulled low should go to FLASH code, get some LED/GPIO action early in Reset_Handler.

Would suggest instrumenting while(1) loops like Error_Handler(), HardFault_Handler() and perhaps Default_Handler(), in case things get stuck there, or clocks/PLL don't start as anticipated.

Run from default HSI/MSI without PLL or HSE, see if behaviour changes.

[AScha.3]

Hi,

>we can see this 3.3V rail will be completely discharged within 0.288s

Is VDD really down to ~ 0 V at the cpu ?

Just try : connect a 470 Ohm from VDD to GND , to full discharge it on power off.  

[TDK]

The chip has brown-out logic, it's unlikely not to be running code somewhere. You can attach a debugger without resetting or downloading to determine where it's at.

Consider enabling the hardware watchdog in option bytes to avoid issues during startup.

[Andrew Neil]

---

@TDK wrote:

You can attach a debugger without resetting or downloading to determine where it's at.

---

Indeed you can!

@LZhan.13 that's described in the link I posted earlier:

https://community.st.com/t5/stm32-mcus-embedded-software/processor-stuck-if-i-run-code-without-debugger/m-p/802267/highlight/true#M63401