Chip popping off SCM20260N module

[C_Born]

In the last batch of six boards I’ve run through the reflow oven, in three of them the Winbond 25Q128JVPQ chip has popped right off the SCM20260N module and ended up 10mm or so away.

Same temperature profile I’ve used for EMX, G120, and previous 20260 boards, same PCB as previous 20260s, never had any problems before.
These were from a new batch from Digikey, the modules were removed from their bags immediately before placement and reflow, they haven’t been left sitting around.

I know the bag says bake @ 125C for 24 hours, I didn’t think that would be necessary for new and freshly unbagged modules. Is that going to be necessary from now on, did I just get a bad batch, have I just been lucky for the last 13 years?

And if I do need to pre-bake, any recommendations for a low-footprint method?

[C_Born]

I’m thinking I could use something like this as a starting point?
Just change the timer to give me the 24 hours…

https://www.amazon.com.au/Soiiw-Sterilizer-Temperature-CH-360T-Equipment/dp/B0C4932SX7

[Gus_Issa]

This is very strange. Baking is required and surrounding humidity makes a difference on how critical baking is but still a chip popping off like that is new to me.

[C_Born]

They were a new batch from Digikey, the SC20 is the last thing added to the board before it goes in the oven, so it is basically open bag, place part, bake. Wouldn’t be out of the bag for more than a minute or two.

Numbers on the bags are all SCM-20260N-C WO:3297

[Mike_Bagnaschi]

Hello,

If the boards were in individual bags those would need to be baked before being reflowed in a reflow oven. We have now changed the way they are packaged. They are now in trays in a moisture proof bag with the humidity card and desiccant bag which makes them an MLS 3 and those are only required to be baked if left open for more than 168 hours before reflow.

[C_Born]

@Mike_Bagnaschi
Thanks Mike, should we expect everything from Digikey to now be in the new packaging, or will we have to wait for them to run down old stock?

I’ll look into pre-baking the boards we still have in hand, 50% loss rate isn’t good odds!

[C_Born]

On to Recovery…

Of the three boards where the chip popped off, after re-positioning and re-baking two of them are working as expected, the other not so much…

Of course I don’t know for sure if the problem is due to the chip problem or something unrelated, as I have another board from a previous batch with identical symptoms. But maybe that popped off just a little bit too?

Anyway, the boards come up with the Loader, and TinyCLR Config will recognize them.
When I ask it to install new firmware, it goes through the Erase, then the Download, then asks to reconnect, but the reconnect fails. I can do this over the physical COM port or the USB GHI virtual COM port, no difference.

Does this indicate the flash was erased and the firmware was successfully downloaded, or isn’t that checked at that stage?

If I ask it to install an App, it does the erase, install firmware, install App, and hangs. Sometimes a big Windows diagnostic dialog comes up saying something about a problem with a COM port.

If I connect via Tera Term the (undocumented?) “T” command prints:

CECC82BA
E97EE07E
CEE07A3C
EE32178D
A91DA61A
6B551FA2
D986582C
75291769
F24C4C5A
C69C6D40
A28DF6AD
DAE12F6F
C9AA145E
24F22BB3
F24C4C5A
C69C6D40
A28DF6AD
DAE12F6F
3F494013
57D0E972
A63DBEDA
5832B62D
A91DA61A
6B551FA2
DC8EA91C
B3A7DC36
41B630E9
45E5F230
6B6FB7F0
AE659BD3
C9AA145E
24F22BB3
41B630E9
45E5F230
6B6FB7F0
AE659BD3

Is it a list of block checksums or similar that could be useful for diagnostics?

I’ve ordered some of the WinBond chips on the assumption that that is the problem, a drying oven for the rest of my stock, and I’ll hold off ordering more modules as long as possible to try and get the new packaging!

[Gus_Issa]

I would always bake them to be safe anyway. It should be an easy process.

[C_Born]

Can do, once I get that drying oven!

It is one more (long) step in the process though, and we’ve been reflowing EMX and G120 boards since around 2011 and never had this problem.

I do like the speed of the SC20 - I’ve been doing some code mods for one of the sites on the G120 board, and I can’t believe how long it takes to boot up - but I miss the stability of NetMF on the EMX and G120 boards, things like hibernate/power save and WinUSB/MassStorage switching just work, while with TinyCLR on the SC20 we are still waiting for something that won’t hang our systems without a ton of workarounds. NetMF on the SC20 would have been so nice!

Re my question in previous post, do the symptoms I describe sound like it is the flash chip at fault, or point to something else? I did notice once of those itty bitty resistors had been dislodged by the errant flash, did my best to reposition it but they are hard to see.

(I asked my partner, same age as me, if he could help, but he said he had trouble seeing the board!)

[C_Born]

Hopefully this will get me back in business!

It has a purely mechanical 1-hour timer (with a cute little bicycle-bell times-up chime), which I planned to bridge out with a switch until I realized it was much easier to 3D-print a slip-on lock-ring to disable the timer progressing.
Plug it into smart-socket with a programmable timer in Home Assistant and we are right to go - and if my wife wants to use it for her hair/nail things it takes just a second to restore to pristine.

[C_Born]

@Mike_Bagnaschi

My latest SCM-20260N delivery.

The module is wrapped with sticky-tape component-side to a piece of cardboard in part of a cut-off plastic tray, then enclosed in a ziplock bag. There is no dessicant, no humidity card, and now no warning anywhere about needing to pre-bake.

[Gus_Issa]

I believe these are marked for highest MSL level for “always bake” in the system. Not sure how this is reflected it their packaging.

[C_Born]

@Gus_Issa
This is a step back from the previous packaging, which as least had the pre-bake requirement on the bag. Compare to the way the RAM chips that came in the same shipment were packaged.

[Two of the SCM20260N modules from my last batch had faulty RAM. They work fine until I extend the heap, when one fails completely, the other sporadically. I wrote some memory test code, on one module the RAM doesn’t work at all, on the other it fails at only a few locations. I could possibly optimize my code to reduce RAM use so I don’t need the external, it is pretty close. But I bought these to have a go at repairing them.]

DigiKey just sent another module my way, I’ll be interested to see how this one is packaged!

[Gus_Issa]

You can see MSL3 on this package. This means there is a level where you may not have to bake. However, we require to bake always to always bake, even though we have improved our packaging and modules go on trays now making it easier for volume orders.

[C_Born]

@Gus_Issa
Exactly, so why does the new packaging say nothing at all about baking or moisture levels? If somebody who wasn’t part of this ongoing discussion purchased a module from DigiKey they would have no indication that pre-baking was required. Did DigiKey drop the ball on this one, was there a breakdown in communications somewhere in the supply chain?

[Gus_Issa]

We are already looking into this.

[C_Born]

Another day, another delivery

This one doesn’t even have the cardboard (possibly a minor dessicant )
You can see the PTC fuses in the same shipment are marked “MSL 1” on the label, but nothing on the module label.

[Gus_Issa]

I was told that the modules are now shipping in trays sealed MSL3. I will forward your feedback to production, thanks.

[C_Born]

Another shipment arrived today. No change in the packaging, no dessicant or moisture indicator card, no mention of MSL rating or need to pre-bake.

On a happier note, the last batch I put through the 24hr drying cycle before reflow came out with no chip-popping and 100% success rate!

[Gus_Issa]

A note would help but we do require baking as per docs. I am glad you are no longer having issues.