How to check the authenticity of STM32 chips?

[AChap.1]

Hi everyone,

I'm deep into developing a project that is not only a passion but also a venture I'm financially invested in. I recently ordered a small batch of 50 PCBAs equipped with STM32L476RET6 microcontrollers from a well-known Chinese manufacturer. I've used their services before without any issues, and I’m sure many of you would have heard of them.

However, I've encountered a significant challenge and could really use your collective wisdom. I'm experiencing a troubling 50% failure rate with the STM32 microcontrollers across the boards. While there could be various factors at play, one concern I have is the authenticity of the STM chips.

I intend to discuss this matter with the supplier, especially since I'm contemplating another order of the same microcontrollers. Hopeful a transparent and open communication will help resolve this issue.

I'm attaching a photo of one of the chips on the PCB for reference. It appears genuine and even has the ST logo, but I'm eager to hear your thoughts.

If anyone has insights or advice on dealing with such issues, particularly regarding the verification of component authenticity, I would greatly appreciate your input.

Thank you for your support.

Adrian

[AScha.3]

Hi,

chip looks ok.

>50% failure rate

What failure ? What shows CubeProgrammer , when connecting to "bad" chip ?

[AChap.1]

Hi @AScha.3  and thank you for your interest.

Firstly, I should clarify that I haven't tested all 50 boards. My initial test on one board was unsuccessful, leading me to suspect a faulty unit. After some troubleshooting, I tried another board, which functioned as expected. This pattern of intermittent failures led me to question the reliability of the batch, especially since my project's design has evolved, making these specific boards less relevant to my current needs. Consequently, I haven't conducted a comprehensive test on all units but the sporadic failures raise concerns about the integrity of the batch.

Regarding your question about the CubeProgrammer, I typically use it for batch processes, but at this stage, I was interfacing the boards with CubeIDE for initial checks. The recurring error I encountered was:

"Target no device found

Error in initializing ST-LINK device.

Reason: No device found on target."

I've double-checked all power connections and everything seems in order, I connect another one and it would work.

While I plan to continue investigating, I'm also keen to gather insights from this community. Any thoughts on how to approach this issue, especially people’s thoughts on whether we should take steps to verify the authenticity of components.

Thanks again for your engagement.

Adrian

[waclawek.jan · Accepted solution]

As much as counterfeiting is a real concern, I would double down on what @AScha.3 wrote - it's more likely that the problem is elsewhere. Bad solder joints, problematic power source, problematic grounding arrangement, problematic (too long, bad contacts) SWD cable come into mind as potential candidates.

JW

[TDK]

+1 to what others have said. Chip looks great, likely the problem is elsewhere.

There are a limited number of things that can go wrong when programming. I would suggest going through them systematically. Verify power supply, verify NRST is going high, verify connectivity between SWDIO/SWCLK pins and programmer.

[AChap.1]

Thanks @waclawek.jan 

I appreciate your perspective, and you're probably right. Counterfeiting is a concern, but it's more practical to focus on the tangible aspects of the issue first, like the assembly quality and the setup used for testing.

I've started revisiting the assembly process, paying closer attention to potential issues with solder joints and the overall power setup.

I'll take a systematic approach to troubleshooting these aspects, and I'm optimistic that this might lead to identifying the root cause.

Thanks for your input.

Adrian.

[AChap.1]

Hi everyone,

I'm pleased to share that I've identified and resolved the issue I was experiencing with my boards. It turns out the root cause was poor solder connections. After reflowing these joints, the programming problems I encountered disappeared, and the boards are now functioning as expected.

I wanted to express my gratitude for the insights and suggestions shared by this community. Your support was invaluable in troubleshooting this challenge. It's a relief to know the exact cause and to have a solution in hand.

Many thanks,

Adrian.