cancel
Showing results for 
Search instead for 
Did you mean: 

Two Resets Required for STM32G474

Ryan Coleman
Associate II

Hello All, 

I'm having a problem with an STM32G474 on a custom board. 

Overview of Fault

First, weird behavior of the IWDG was observed. A hard fault was generated intentionally after 10 seconds of run time and no reset behavior was observed. Then, a while(1) { } was introduced after 10 seconds of run time and this generated a partial reset where the system decreased it’s overall power draw to 2mA but never fully reset, a state which we will call “Reset Purgatory.” Pressing the reset button on the board completed the reset and the code began to run again. 

It was also observed that while running, pressing the reset button on the board puts the system in to Reset Purgatory and only another press of the button completes the reset allowing the code to run. The same behavior was observed for the chip reset button in Cube IDE. We realized this behavior was observed early on in the boards development but normalization of deviance took hold and the issue was not investigated further. 

The RCC_CSR register was then checked (more information may be found on page 327 of RM0440) and it was discovered that the LPWRRSTF bit was set. This bit is “Set by hardware when a reset occurs due to illegal Stop, Standby or Shutdown mode entry.”

When this and the other RCC_CSR flags are cleared and no reset occurs the system can be placed in standby, restarted, and the flag remains 0. If a reset occurs by the IWDG, physical reset button, or software reset button in the IDE, the LPWRRSTF bit is re-set until cleared again by software. The bit is also set after the MCU is power cycled and flashed by the debugger. 

Does anyone have any idea what could cause this? We have the 100nF between nrst and gnd and our option bytes are as follows: 

RyanColeman_0-1729211736247.png

RyanColeman_1-1729211747965.png

 

**The rest is mostly relevant to our application so skip if you'd like**

This is a concerning discovery as any reset generated will, by our limited understanding as further testing is needed, put the system into a state where it is drawing 2mA. If our pack is stored at it’s nominal minimum voltage of 13V it has about 400mAh of capacity remaining according to the graph found at this link 3500mAh 18650 Li-ion cells' discharge capacity test (Sanyo NCR18650GA vs Panasonic NCR18650GA vs LG MJ1 vs Samsung INR18650-35E). That 400mAh of capacity will give approximately 8.5 days of life before the pack is drained to its absolute minimum voltage of 2.5V/cell, making it non rechargeable and bricked. A fully charged pack with this current drain will last approximately 72 days. This window lines up with our real world failure information, limited as it may be. 

 

What conditions are necessary for this fault to occur? 

The MCU must experience a reset from any source we have listed above or some other method of reset that is yet unknown. Because mcu resets/reset flags have not been recorded in our NVM, it’s unknown whether or not this fault has occurred. It seems likely that it has based on the circumstantial evidence.

1 REPLY 1
PGump.1
Senior II

Hi,

I haven't used the G474 (as yet). But I have had similar problems with other parts over time.

I'm guessing that you have two, or more, problems that are overlapping...

However, before starting down that path - have you checked that ALL the VCC and VSS pins are connected? Also, the NRST cap of 100nF maybe a bit too much - the NRST pin is bidirectional, perhaps a 10nF would be better.

Are you sure the IWDG is configured correctly?

Have you implemented a HardFault handler? And all the other Fault handlers?

I assume you are using an RTOS (I only get HardFaults with an RTOS)?

Are you using the RTC, or Wakeup logic? This logic uses a separate reset system - are you doubly initialising things that don't like it...

Kind regards
Pedro

 

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.