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:
**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.
We're using the boot0 pin for FDCAN, so it isn't grounded. My understanding is that our boot configuration is taken from option bytes, not the state of the BOOT0 pin. I'm attaching a screenshot with nBOOT0 included (I realize that was clipped from my original post.
Looking (again) at the TRM, I think we have our option bytes configured incorrectly. We want nSWBOOT0 = 0 and nBOOT0 = 1. Can you confirm this is right?
From page 90 of RM0440:
