2024-05-16 03:18 AM - last edited on 2024-05-17 01:29 AM by SofLit
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:
Currently we are at a dead end situation, does anybody has any suggestions?
Thanks a ton!
2024-05-17 05:17 AM - edited 2024-05-17 06:26 AM
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:
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.
2024-05-17 05:48 AM
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
2024-05-17 06:11 AM
@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.
2024-05-17 06:34 AM - edited 2024-05-17 06:55 AM
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 ...
2024-05-17 06:58 AM
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:
2024-05-17 07:01 AM
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
2024-05-17 07:22 AM
This is the screenshot of the ST-Link utility after comparing the faulty PCB flash memory:
2024-05-18 12:53 AM - edited 2024-05-18 12:55 AM
Quoting from the initial post:
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?
2024-05-18 05:37 AM
@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. 😉
2024-05-18 12:59 PM
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.