MSP430FR4133: BSW programming problem on ~1% of units

HI Josh,

So you are programming the MSP430 using the SBW pins and it is already mounted on a PCB, correct?

How long are the wires from the programmer to the MSP430?

Do the units that fail have the same LOT code # printed on the package, or do they vary?

>So you are programming the MSP430 using the SBW pins and it is already mounted on a PCB, correct?

Correct.

>How long are the wires from the programmer to the MSP430?

For each conductor (TEST, RST) there is ~11cm of jumper wire + ~6cm of PCB trace between programmer and MCU pin. The TEST and RST traces are isolated home runs.

>Do the units that fail have the same LOT code # printed on the package, or do they vary?

All of the samples of both failed and good units I have (5x of each) have the same lot code (26AP3ZT). All the chips for the run were purchased in one batch directly from Digikey.

Thanks!

-josh

>So you are programming the MSP430 using the SBW pins and it is already mounted on a PCB, correct?

I just transplanted the MSP430 from one of the failed units to a carrier board with no connections besides Vcc, Gnd, TEST, and RESET and a decoupling cap.

I see identical errors when trying to access this isolated MSP430 over BSW, both coming from MSPFlasher and looking at the signal traces. 

-josh

Hi Josh,

Ok, thank you for the detailed debugging.  Just for my records, what version of CCS are you using?  Also, this may not help, but can you try using Uniflash?

The reason I ask is MSPFlasher is not the latest and we don't support it.  It has been supplanted with Uniflash.

Next, I would like to see if I can get 1 or 2 of both good and bad units from you.  I don't see you are with any company in our system.  This may be a complication because we have a process to go through to accept any returned material for failure analysis.  Can you provide any additional information?

>Just for my records, what version of CCS are you using? 

12.1.0

> Also, this may not help, but can you try using Uniflash?

Yes, UNIFLASH Version: 8.4.0.4458 gives similar results:

>Next, I would like to see if I can get 1 or 2 of both good and bad units from you. 

>I don't see you are with any company in our system. 

>This may be a complication because we have a process to go through to accept any returned material for failure analysis. 

>Can you provide any additional information?

I am happy to provide sample and additional information. I will contact you directly over private message.

Thank you. 

Hi Josh,

Before I forget, by chance, did you remove a good device from its PCB and replace with bad device and verify it fails?

Ok, it appears you will have to go through our Customer Returns procedure found here-> https://www.ti.com/support-quality/additional-information/customer-returns.html

Since you purchased through a distributor (Digikey), there is a link with instructions.

Let me know if you need help.

> did you remove a good device from its PCB and replace with bad device and verify it fails?

Yes. Fault follows the MSP430 IC in both transplant directions. 

Still working though the process with Digikey...

Hi Josh,

The devices have been received and our test team has test these and reference devices and found no issues.  Next will be bench testing.

Great. They should be able to reproduce the error by doing any read or write memory access over BSW. Do not hesitate to ask of any questions come up. Thanks!

Hi Josh,

I have your devices but don't have a test socket that is 56pin SSOP, so I'm reaching out to our FA lab to see if they have one I can borrow.

Since it only requires connections to 4 pins (DVSS,DVCC,SBWTDIO, & SBWTCK) to reproduce this issue, you can easily just connect 4 pin test hooks/grabbers directly to these pins and connect the other ends to the corresponding pins on an MSP programmer. 

Alternately, since these these pins happen to all be adjacent to each other on the 56-pin package, you can solder down just this group to any proto carrier board you can find that has anything close to matching pitch (or any one that has 2x or denser pitch). 

Finally, it is not hard to cut the ends off of 4 jumper wires, strip those ends, and then solder those leads directly onto the pins. Then plug the other ends of the jumpers to the MSP programmer pins.

Thanks!

Hi Josh,

Yes, I was thinking the same thing.  I haven't heard back from our FA lab and don't want to was more time, so I'll see what I can rig up and let you know.

I got back the final report from TI stating...

"The TI device passed automated testing using the current production test program
In conclusion, TI could not verify the customer reported issue and the customer return has been deemed
Trouble Not Identified (TNI)"

I quadruple checked those isolated parts before sending them using fresh programmers on fresh machines. I am almost certain that these parts are defective and attempting to program them over BSW as described above will produce the indicated errors.

Do you know if the "automated testing" suite using the "current production test program" described in the report includes programming the IC specifically over the BSW interface using the publicly available tools?

Hi Josh,

I'll be setting this up today for testing.

Thank you! Let me know if any questions or problems!

Hi Josh,

I finally managed to mount your devices on an EXP-MSP430FR4133 Launch pad.  2 of the units failed to recognize the device ID.  I tested twice and confirmed connections were solid.  I even tested 2 known good units and they program with no issues.  I reached out to our test group to see if they can test again to verify my observations.

Thanks for confirming the issue. It is a very interesting one!

Hi Josh,

When these devices fail programming, is it on the very first attempt?  In other words, brand new device, first time?  

Yes, failure happens on fresh devices during factory programming, which is next step after PCBA. Programming is done in a automated fixture that immediately rejects the unit on any error.

Any updates? Thanks!

Any updates on this issue? Thanks!