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!

[waclawek.jan]

How are these devices powered, from some external power source, or from a battery which is permanently connected?

More precisely, was there a power off/on cycle after initial programming?

JW

[Farhadpi]

This is the screenshot of the ST-Link utility after comparing the faulty PCB flash memory:

 

 

[waclawek.jan]

Quoting from the initial post:

• 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 cannot reproduce this issue at our place, but the customer reproduces after 5 or more iterations of battery charge and discharge cycles.

These appear to contradict: the customer appears to complain about consequences of "battery charge and discharge", whereas you appear to have tested "removing and re-applying power" but that failed to reproduce the issue. Is this correct?

Have you, at your place, tried battery charge/discharge cycles; or something mimicking this process like a power supply being slowly brought down and then up again?

If not, and if what I wrote above is true, then, as @MM..1 said above, this much like sounds like brownout problem. Then the questions are:

- how are BOR options set?

- couldn't the observed behaviour be consequence of VBAT brownout?

You definitively should try to reproduce the problem at your place, first; and then observe, what does the "frozen" code do.

JW

PS. @David Littell : I see your point and generally subscribe to it, but the pulldown on BOOT0 may be not absolutely necessary if the options are consistently set to ignore that pin, would you agree?

[David Littell]

---

@waclawek.jan wrote:

...

PS. @David Littell : I see your point and generally subscribe to it, but the pulldown on BOOT0 may be not absolutely necessary if the options are consistently set to ignore that pin, would you agree?

---

Yes, absolutely agreed assuming they know what they're doing (for both hardware and software).  Evidence of that isn't exactly overwhelming in this case.  ;)