MCU STM32G030K8T6 Frozen

EverShine · ‎2024-05-16

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:

Screenshot 2024-05-16 112637.png

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!

Farhadpi · ‎2024-05-17

As we mentioned before, we do not use any pull-down resistor in this circuit. For this series of MCUs, there are three options for BOOT configuration:

BOOT0 pin
BOOT_LOCK bit in the FLASH_SECR register
Boot configuration bits nBOOT1, BOOT_SEL, and nBOOT0 in the user option byte

We use the third option.

Additionally, for your information, we use the similar MCU in other projects without any external pull-down resistors and have never encountered any issues.

For this faulty PCB, I attempted to place a pull-down resistor to observe any effect. However, after connecting a pull-down resistor to Pin 25 (PA14), nothing changed—the MCU still freezes and does not operate!

I already checked the Device Errata and no similar issue found.

waclawek.jan · ‎2024-05-17

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

David Littell · ‎2024-05-17

@Farhadpi wrote:
As we mentioned before, we do not use any pull down resistor in this circuit.
For this faulty PCB, I attempted to place a pull-down resistor to observe any effect. However, after connecting a pull-down resistor to Pin 25 (PA14), nothing changed—the MCU still freezes and does not operate!

...

Oh, according to your traces it's clearly doing something.

And as mentioned before, BOOT0 should always, always, always be pulled down (10K is fine) as a matter of good practice. If you intend to use the MCU's Bootloader or RAM start then a mechanism (usually a jumper to VDD) is needed to drive BOOT0 high.

As an aside, ST didn't do anyone any favors by combining BOOT0 and a debug pin. That was pure stupidity.

MM..1 · ‎2024-05-17

From this graph MCU isnt frozen but reset every 260ms. And too MCU_TX levels is ugly.

HOW is your app CLK , how is managed undervoltage protection ...

Try on frozen board connect regulated PSU over Vcc 2V8 and go up slowly ...

Farhadpi · ‎2024-05-17

We placed a resistor temporarily to check if it would have an effect, but there is no dedicated place for such a resistor in the design.

As we mentioned earlier, we produced 1500 units and delivered them to our customer. Some of them failed after a couple of days or after a few charging cycles.

I think the discussion about the BOOT pin is irrelevant in this case. Even in the evaluation board from ST, "STM32 Nucleo-64 boards (MB1360)," does not use an external pull-down resistor on the BOOT pin. Therefore, this discussion should be concluded as it does not pertain to our issue.|
see below:

MM..1 · ‎2024-05-17

Dont waste time isnt BOOT0 problem, test as i write Vcc and maybe unoficial BOR is source of this trouble. As asked here What are the BOR levels for STM32G030 ? - STMicroelectronics Community

Farhadpi · ‎2024-05-17

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

waclawek.jan · ‎2024-05-18

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 · ‎2024-05-18

@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. 😉

EverShine · ‎2024-05-18

We use the STM32G030K8T6 MCU. As far as I see, this doesn't have a BOR per the reference manual or the datasheet.

By the way, our debugger was misleading us, showing it as a frozen MCU. After a thorough analysis of the behavior of the failed part, we understand that, after the execution of MX_GPIO_Init, MCU is executing the Error_Handler. Currently we are examining, why the GPIO initialization is failed in some devices after the completion of charge and discharge cycles.