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]

Seems to be the same problem here:

https://community.st.com/t5/stm32-mcus-products/mcu-stm32g030k8t6-hangs/m-p/665657

@PLER 

[David Littell]

I wonder if his BOOT0 pin is left floating too?

[Farhadpi]

Hi,

Boot0 pin is left open, we use this pin for debugging/programming.
Is there any related reason for asking?

[Andrew Neil]

Leaving it open makes it susceptible to noise.

Have a resistor to pull it to your "normal" level - you can override that for debugging/programming

[Farhadpi]

Do you mean pull it up?

B.t.w. I did not see any point regarding an external pull-up/down in the application note.

and it cannot be done by internal pull up/down resistor?

[Andrew Neil]

To boot from main flash (ie, run your code), you want it pulled low:

Does your application use Standby mode?

Are you working with @PLER on that same product they posted earlier?

[Farhadpi]

Yes, we utilize Stand-by mode.
We're collaborating on the same product with @PLER.

Understood, for running the code from Flash memory, the BOOT0 pin should be low.

Considering this, there would be two questions:1. Is it possible to use the internal pull-down for the BOOT0 pin?
2. In the event that the Boot pin get noise and resulting in the MCU freezes, would a reset or re-powering typically resolve the issue? However, in our scenario, the device works after re-flashing the MCU.

[Andrew Neil]

---

@Farhadpi wrote:

We're collaborating on the same product with @PLER.

---

Then why start a whole new thread, when you already had one existing on this very problem?

---

@Farhadpi wrote:

1. Is it possible to use the internal pull-down for the BOOT0 pin?.

---

Not familiar with this part, but I guess not: the internal pull-up/down is probably only available when the pin is configured as a GPIO - not BOOT0 ?

---

@Farhadpi wrote:

2. In the event that the Boot pin get noise and resulting in the MCU freezes, would a reset or re-powering typically resolve the issue? 

---

I wouldn't rely on it!

A bad value on BOOT0 could end up with you running from RAM, or in System Bootloader mode - so I'd say it is entirely possible that the Flash could get corrupted.

EDIT:

And @PLER did previously report that you do see Flash corrupted.

[EverShine]

When we re-flash the firmware, it works absolutely fine again, without pulling the BOOT0 pin up or down. What I don't understand is, how the device can work just by re-flashing the binary?