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?

 

[waclawek.jan]

Post content of Option Bytes.

JW

[EverShine]

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

[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.

[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.

[MM..1]

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

[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?

[Farhadpi]

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]

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]

 

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:

1. BOOT0 pin
2. BOOT_LOCK bit in the FLASH_SECR register
3. 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.

[David Littell]

---

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