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!

[EverShine]

Yes, we can try this.

[EverShine]

Using the STMFlashLink Utility, we have been reading the device memory and saving to a file. Later we were  comparing the saved file to the original firmware file. Both the files were identical.

[EverShine]

I will get back to you reading the Option Bytes.

[EverShine]

Sure. I will get back to you reading the Option Bytes.

[EverShine]

Please, find the option bytes from the below picture.

 

[Andrew Neil]

Is that what you expect, or what you read-out from a "failed" device?

[Andrew Neil]

---

@EverShine wrote:

So, this proves that there is no corruption in flash.

---

Well, no:  it shows that there wasn't corruption in the ones you examined - but it doesn't prove that it never happens.

And @PLER confirmed that they had seen occurrences of Flash corruption.

This is all in the nature of undefined behaviour ...

[EverShine]

Option bytes remains same for the failed and the working device. We did not see change in the Flash contents and the option bytes.

[Farhadpi]

Hi,
I measured some test points on the frozen MCU and observed that some pins are behaving oddly, like this:

1. NRST:

2. MCU_TX:

3. TP9/TP10

the rest of the Test Points like 

TP11/12/13/14/15/16/17/19

are low.

[David Littell]

Is a pull-down resistor now installed at BOOT0?  If no, why not?

Have you evaluated the Device Errata in the context of your problem?