Defective processors

[mbeffa]

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

[Andrew Neil]

---

@mbeffa wrote:
 should not enter the distribution, authorized or not.

---

No: that is the big difference between authorised and not!

Using an Authorised Distributor guarantees that you're getting good product

A non-authorised distributor could well be buying on the so-called grey market ..

---

@mbeffa wrote:
My hope was you STM ...

---

Again, this is a public community - not direct ST support.

Most participants are not ST staff.

[unsigned_char_array]

Are you sure they are really defective? One potential issue is you can be running them outside of their operating range. For instance using an incompatible crystal that may or may not oscillate on some MCUs. Or maybe you are clocking peripherals too high.
Have you debugged a board? Is the code stuck somewhere? Have you tried toggling the I2C GPIO pins directly?

[Andrew Neil]

---

@Andrew Neil wrote:

---

@mbeffa wrote:
If we replace the processor with a stock bought from Digikey, the processor
always works.

---

So the problem definitely seems to be with your Chinese "distributor".

---

Hmmm - maybe  I should take that back...

It could be an assembly problem; eg, dodgy solder joints.

In that case, simply re-flowing the original part would have fixed it.

As @unsigned_char_array said, you need to do some debugging, including some testing of the removed parts.

Perhaps try putting one of the removed parts back onto a board?

[unsigned_char_array]

Like @Andrew Neil wrote put an MCU back on one board. Or hopefully you kept one defective board unchanged. I'm really curious about it.
Without it on a board it's very hard to see what's wrong with it. Unless you take an x-ray of it and compare it to an x-ray of a working MCU.

[ABurc.2]

Hi All

I work with Mihai Beffa, who started this thread. I managed to make some tests with the bad boards.

For context, the card is a slave on an I2C bus. Measuring the SCL line, I realize it can not be driven low enough by the master (don't go lower than 1.92V)

Decide to make the SCL (PA15) output push-pull (no I2C initialisation, no master connected) and toggle the pin with 1Hz. The pin goes from 1.36 to 3.3V. The resistance measurement between Vcc and PA15 has about 48 ohms for the bad microcontroller and a few megs on the good ones. 

[waclawek.jan]

So the damaged pin is PA15? (PB15 has been mentioned previously - a typo?)

Is this consistent across all damaged chips?

What does exactly "JTAG programming" entail? Is it a true JTAG, i.e. not SWD? I'm asking, because PA15 *is* a JTAG pin. If yes, is there any device chained to PA15 during programming? What equipment is employed? Is power sequencing OK before/after programming? Isn't there 5V applied to PA15 during programming, or at any other time? 

JW

[ABurc.2]

The used pins are SCL(PA15) and SDA(PB9).

The measurement is pretty consistent on all the bad cards I measured (about 4), and the value is between 38 and 60 ohms.

Programming interface is SWD, and there are no existing chances that PA15 will be powered with 5V.

The device used for programming was ST-LINK / V2 (official version from ST), and for most of them, the probe included with the NUCLEO-F303RE, which is used for programming and testing in production. 

I don't understand what you mean by power sequence, but on the automated test, the sequence is as follows:

- power the card

- program custom bootloader using swd with STLINK included on the Nucleo -F303RE and "STM32_Programmer_CLI.exe"

 - repower the card (few delays on power up and down)

- Load the main firmware over I2C with the processor on the NUCLEO as a master.

- Repower again

- start testing..

 The bad cards can not start the main firmware update because of the I2C communication error.

[mbeffa]

Sample of bad processors attached.
All were purchased from LCSC.COM

[STOne-32]

Hi @ABurc.2 

Thank you for the time doing these tests, much appreciated.

Based on this experiment, PA15 is physically damaged, it could be an EOS or an extreme stress above our AMR (Absolute Maximum rating) current or voltage creating it. Do you have in your board or application another rail at 5volts, 12Volts or 24 Volts?

I never saw such behavior of fresh parts so far and it seems more a handling issue or accidental programming done somewhere.   It is quite impossible that such device is damaged, and we shipped it to any distributor   - we have basic tests factory of I/Os able to catch such issue called I/V curve on each individual pin and test at each MCU manufactured.

Regards,

STOne-32.

[ABurc.2]

Hi,

Here are the defective Microcontrollers:

 And here is the new one  we replaced  with