MCU STM32G030K8T6 hangs

[PLER]

Hi all,

 

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. So far so good.

 

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 just stops operation.

It stops at the following line of code:

 

We found a lot of high dV/dt on the powerline and think this is causing the MCU to hang although we cannot reproduce on a single piece.

If we test products randomly on bench or at our desk it doens't have any issues.

 

Currently we are at a dead end, does anybody has any suggestions?

 

[Tesla DeLorean]

Make sure HardFault_Handler and Error_Handler output actionable data and assert a GPIO or LED rather than just while(1) silently. 

Make sure you're immediately ready to deal with interrupts coming from the TIM or other sources as you initialize pins and clocks.

[Andrew Neil]

What development tools do you have?

It should be possible to connect to a running target without downloading & resetting:

https://community.st.com/t5/stm32-mcus-boards-and-hardware/connecting-to-running-target/m-p/272666#M9437

 

---

@PLER wrote:

During this test 1 to 3 products are failing

---

Is consistently the same 1-3 which exhibit this "hang" ?

Is it consistent where in the test sequence the "hangs" start occurring?

 

---

@PLER wrote:

We found a lot of high dV/dt on the powerline and think this is causing the MCU to hang 

---

Have you tried addressing that?

ie, if you prevent the high dV/dt, do the failures stop?

 

---

@PLER wrote:

products will be charged and de-charged between 3 to 10 times.

---

So, apart from high dV/dt, you could also be having brown-outs? Have you looked into that?

 

EDIT:

What does it take to recover from a "hang" - just a reset? a full power-cycle? other?

 

Please use this button to properly post source code:

 

 

[PLER]

---

---

@PLER wrote:

During this test 1 to 3 products are failing

---

Is consistently the same 1-3 which exhibit this "hang" ?

Is it consistent where in the test sequence the "hangs" start occurring?

---

It is random, there is no pattern.

 

---

---

@PLER wrote:

During this test 1 to 3 products are failing

---

Is consistently the same 1-3 which exhibit this "hang" ?

Is it consistent where in the test sequence the "hangs" start occurring?

 

---

@PLER wrote:

We found a lot of high dV/dt on the powerline and think this is causing the MCU to hang 

---

Have you tried addressing that?

ie, if you prevent the high dV/dt, do the failures stop?

 

---

@PLER wrote:

products will be charged and de-charged between 3 to 10 times.

---

So, apart from high dV/dt, you could also be having brown-outs? Have you looked into that?

 

EDIT:

What does it take to recover from a "hang" - just a reset? a full power-cycle? other?

 

Please use this button to properly post source code:

 

 

---

If I supply high dV/dt to a single product nothing happens to the product. The problem only arises at the burn in facility (which is not the same location), where they are connected in group to the same mains.

At our lab I made a test setup with the same simple USB charger. Interrupting the mains on an irregular base generates spikes which ripple further via the power path into the system. The ringing is visible on the Vdd of the MCU. Besides the ringing, the supply voltage is flat and stable.

In case the MCU comes into a hang state the only way to get out is by re-flashing the code. Resetting or power-cycling the MCU are not doing the job.

 

The occurrence of the error is very random, no pattern is visible. This makes it a very hard error to find.

 

The burn-in cannot be changed.

---

 

 

[Andrew Neil]

---

@PLER wrote:

---

---

In case the MCU comes into a hang state the only way to get out is by re-flashing the code. Resetting or power-cycling the MCU are not doing the job.

 

---

Can you read-back the flash content of a "hung" chip?

If so, does it verify against the original code image?

Does the code write to flash?

[Pavel A.]

In line 423, are you sure that pin named STATUS_LED_PIN should be in mode AF1_TIM3?

 

[waclawek.jan]

How are option bytes set? Namely, BOR_EN and BOR_LEV bits.

JW

[PLER]

It is confirmed to me that they are set.

[Tesla DeLorean]

BOOT0 pulled LOW or Floating?

Hung? Like a Latch-Up condition, or inexplicably dead in a while(1) loop, or in an infinite IRQ storm because the source hasn't been cleared? Ponder how you might determine this.

[PLER]

Boot0 is left floating, although it is connected to the TAG connector.

[Andrew Neil]

Same question recurs here, from @EverShine :

https://community.st.com/t5/stm32-mcus-products/mcu-stm32g030k8t6-froze/td-p/675163