MCU STM32G030K8T6 Frozen

[EverShine]

We have a product containing the STM32G030K8T6 MCU. The code is working like expected and the product is meeting all specifications. The product is battery powered and can be charged via USB.

If the product is assembled it will go into a burn-in test where 70 plus products will be charged and de-charged between 3 to 10 times. During this test 1 to 3 products are failing, and with failing I mean the MCU does not advance further or freeze as shown in the below picture.

It stops at the following line of code:

• Below is the configuration of the HW.
  • MCU: STM32G030K8Tx
  • USB to UART Chip: CH340E
  • UART Port:  USART1
• Below are our observations.
  • After removing power to the MCU and the rest of the circuitry completely and re-applying the power again, the MCU remains frozen at this step.
  • We also checked for flash corruption. When we read the Flash (Device memory) and save the file and compare the saved file with the original binary, there are no differences. So, this proves that there is no corruption in flash.
  • We cannot reproduce this issue at our place, but the customer reproduces after 5 or more iterations of battery charge and discharge cycles.
  • Also, this issue is not reproducible on every device. Approximately 10 percent of the devices.
  • When we reflash the MCU, then the problem strangely goes away.

Currently we are at a dead end situation, does anybody has any suggestions?

Thanks a ton!

[Andrew Neil]

As I said, having the BOOT0 pin floating gives a very plausible case that the Flash may get corrupted.

And @PLER previously confirmed that you do actually see cases of corrupted Flash.

"Corrupted Flash" means that your code has been trashed - you recover from that by re-flashing.

[EverShine]

We did not observe, flash corruption during our tests. In the failure scenario, when we read the Flash and save the file and compare the saved file with the original binary, there is no difference. So, this proves that there is no corruption in flash.

[Andrew Neil]

Did that include reading Option Bytes?

[waclawek.jan]

Post content of Option Bytes.

JW

[MM..1]

Go back to start from this chaos. You show image stop at this line. In real MCU cant stop at this line.

Primary no debug your device when use standby mode etc. Optimal is debug leds or uart from code.

Secondary your idea reflash repair device , but flash readed is same is absurd. 

My tip device have trouble read right flash data when batery is on low power. Result sw crash.

For real solve you require device, that can reproduce issue. Show here Vcc Vbat voltage values on MCU when fail.

How clock uses your design HSE ?? More info is better.

[Andrew Neil]

---

@MM..1 wrote:

 In real MCU cant stop at this line.

---

If there has been Flash corruption, what the debugger shows will be wrong...

[Andrew Neil]

---

@EverShine wrote:

We did not observe, flash corruption during our tests. 

---

Irrespective of that, having the BOOT0 pin floating is definitely A Bad Thing - so fix it!

[Tesla DeLorean]

Definitely indeterminate start conditions, often resulting in complaints that the part "doesn't start" or "doesn't run my code", when it does actually start, but runs the system loader, etc.

Pull it low externally, so that at reset and as power ramps, it's tending toward zero, and not looking kinda-high. None of your code has run to set an internal high pull-up, unless data sheet says that's the default.

Did the Error_Handler() or HardFault_Handler() ever get instrumented so you'd know if it went off to die in those while(1) loops?

Add code to checksum or CRC the running image, to confirm integrity, so you can catch when/if this happens and you otherwise don't notice.

[Andrew Neil]

---

@EverShine wrote:

• After removing power to the MCU and the rest of the circuitry completely and re-applying the power again, the MCU remains frozen at this step.

---

How long do you leave it before re-applying power?

Do you ensure that the PSU and all caps are fully discharged?  Otherwise there could be just enough to keep it in the "Bad Boot" state...

[EverShine]

Much more than the capacitor's discharge time. Power was removed from the malfunctioning board for a day, but when we turned it back on, the MCU remained frozen when powering up.