2026-01-05 8:39 AM
Sequent Microsystems designs and sells Automation Systems using Raspberry Pi. All our products use STM processors. We use about 10,000 processors per year in different configurations. Generally we do not have any quality problems, but occasionally we run into a defective lot. On a recent run of 30 prototypes using STM32G431CBT6, 50% were defective. We replaced the processors and all boards worked as expected. We buy all out processors from a Chinese distributor.
We saved the defective processors and I would like to know if you would have any interest in inspecting them to find out why they entered the distribution chain, and to advise us how to avoid this problem in the future.
Mihai Beffa
CEO
Sequent Microsystems
2026-01-06 3:14 PM
Thank you. Here is my last question is possible to get with the CubeProgrammer the UID of the defective parts
it is at @ 0x1FFF7590:
This will allow us also to check at the defective MCU the tests at factory and then we may contact you back
Regards,
STOne-32.
2026-01-06 4:13 PM
Hi,
There are only 3.3V and 5V rails on the card, but I don't see how 5V reaches the pin in any situation. How do you explain that changing the part solves the problem if the same card is tested in the same testbed?
Regards,
Alex.
2026-01-06 4:34 PM
Hi,
There is something that might be happening when we first connect the card to the testbed. The card is unpowered, but the I2C pins are pulled up to 3.3V with 2.2K ohms. This could damage the pins?
Alex.
2026-01-06 5:42 PM
Here are the UIDs of the nine microcontrollers we haven't replaced yet:
6E0037000E504D4636383220
25002B000E504D4636383220
29002A000E504D4636383220
40002C000E504D4636383220
4D002A000E504D4636383220
5D0052000D504D4636383220
6C0037000E504D4636383220
5E0052000D504D4636383220
550037000E504D4636383220
2026-01-07 2:11 AM
> There is something that might be happening when we first connect the card to the testbed. The card is unpowered, but the I2C pins are pulled up to 3.3V with 2.2K ohms. This could damage the pins?
Is the ground to which these 3.3V is referenced, connected also the the STM32G431 in question? In other words, does PA15 in question see those 3.3V/2k2 against its own VSS pin?
I am not accusing your testbed of being the source of damage, just pointing out the facts, that
The fact that after replacement there was no damage indicates that the damage occured prior you've connected it to the testbed, but may also be consequence of some unnoticed difference in the details of the testing procedure. A definitive answer would if you'd have a specimen which haven't been touched by the testbed yet is damaged, but I guess you don't have such.
JW
2026-01-07 2:29 AM
Yes, the VSS pin is connected to the GND of the 3.3V source, while the processor Vcc pin is floating. Meaning the PA15 sees the 3.3V.
I modified the testbed so that the two I2C pins remain at 0V when the microcontroller is not powered, but it is too late because all the damaged cards were connected to the old version of the testbed.
I don't quite understand why the pin must be 5V tolerant since I was not exposed to more than 3.3V.
Thanks for the answer, @waclawek.jan. We will see if the problem occurs when the PA15 is not exposed to 3.3V, with Vcc floating.
Alex.
2026-01-07 3:51 AM
Grounds need to be common and mate first on the fixture.
Debug Pod needs to be removed in case its conflicting with the output of the PA15 I2C usage. ie driving HIGH whilst PA15 is LOW in open collector/drain. This might explain mid voltage.
2026-01-07 4:57 AM - edited 2026-01-07 4:58 AM
> I don't quite understand why the pin must be 5V tolerant since I was not exposed to more than 3.3V.
The fact that PA15 has pullup switched on at poweron is AFAIK the sole difference between PA15 and PB9 (the latter is plain 5V tolerant). The former is damaged, the latter is not. Again, I just pointed out those facts, with no conclusions drawn.
JW
2026-01-07 5:04 AM
To explain it with the content of the DS :
+
So unpowered its NOT 5V tolerant, even more: no positive injection allowed (max. current = 0 mA ! ).
->
Your testbed might kill the unpowered cpu, obviously exceeding allowed limits. (current injection)
No need for more investigation...I suppose .