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:

 We buy all out processors from a Chinese distributor.

---

So have you contacted that distributor for support?

Are they an Authorised distributor?

 

Sounds like you should be talking direct to ST rather than posting on this public forum?

Raise a direct support ticket: https://ols.st.com/s/

ST Sales offices, Official distributors, etc: https://www.st.com/content/st_com/en/contact-us.html

[mƎALLEm]

Hello @mbeffa and welcome to the ST community,

We don't handle such requests here in the community. As stated by @Andrew Neil , you need to raise an online support ticket over this link https://ols.st.com/s/

or contact your local distributor or your local FAE.

[STOne-32]

Dear @mbeffa ,

On top of previous comments from @Andrew Neil  and @mƎALLEm , Thank you for posting such comment as other members may face similar experience which is for sure not convenient:

"On a recent run of 30 prototypes using STM32G431CBT6, 50% were defective. We replaced the processors and all boards worked as expected"   -> 50% of defective Parts is not a quality issue but another kind of damage such as reworked parts having abnormal stress. is that possible to know what kind of issues they have at board level :

• Excessive current  
• Continuous reset
• Not booting and executing startup before jumping to main  

If possible, to provide the package top picture and also provide all of this information to our https://ols.st.com/s/

Thanks again 

STOne-32

[mbeffa]

This is not a rework issue. The defective boards are factory assembled,
just like all out boards.
Virtually all defective processors behave the same.
We program the processor through the JTAG interface, then we talk to the
processor through the I2C interface. A defective processor programs
normally through the JTAG, but the I2C port is dead.
If we replace the processor with a stock bought from Digikey, the processor
always works.
On the lot of 50% defective, we used I2C port1 (pins PB9, PB15), STM32G431

[Andrew Neil]

---

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

Edit: or perhaps not - see below.

Again, have you contacted that distributor for support?

Are they an Authorised distributor?

Are you sure they are shipping you new, genuine product?

 

---

@mbeffa wrote:
 the I2C port is dead.

---

How do you determine that?

Do the pins work as plain GPIO?

Have you done any testing on the removed, "faulty" chips?

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

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

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

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