MSP430F2418: Programming Issue

Hi Charlie,

Have you been able to successfully program these devices in the past and now suddenly you are finding some fail blank erase?  Are the devices that are failing blank check new (never before programmed) devices?

Hi Dennis,

We were able to program these devices successfully in the past.  For some reasons, we are not able to program them because of blank erase.  We've only seen this issue on handful of devices and majority of them work fine.

Hi Charlie,

Can you look at the date code markings on these parts and see if the ones that fail have same or different date codes compared to good parts.

Hi Dennis,

So far, we are seeing the same date code (098XPHWG4) on two problematic parts we have.  It is different from the date codes on the good parts we have.

Hi Charlie,  

Do you know if these devices were purchased from the same distributer/supplier that you normally get these devices from? 

Hi Charlie,

Our Quality team is asking if you can take a picture of the markings on the chip?

Hi Dennis,

Yes, these parts were purchased from the same distributor that we normally purchase from. 

Hi Charlie,

Thanks for the update.

Ok, let me make sure I understand completely.  Most of those devices with markings (098XPHWG4) you were able to program, erase and re-program with no problem, correct?  But you have a few that you program, erase, but then fail blank check when trying to re-program, correct?  Are you able to provide a quick photo of one of these devices showing the markings?

Regarding the connection of the MSP-GANG programmer to the target MCU, it sounds like you are programming the MSP430 installed on your PCB and powered with a battery, correct?  What is the battery voltage?

I see this caution in the MSP-GANG documentation regarding using external power for the target and this external power should be connected to pin 4, not pin 2 as you mentioned above.  Can you check this?

Hi Dennis,

Please see attached picture for the MSP430 markings with blank erase.

Thanks Charlie,

I wanted to double check this with our Quality group in case there is a known issue with this date code.

I'll respond shortly with their results.

Hi Dennis,

Since this issue came up pretty recently.  We are still in the process of gathering more information as far as date code.  So far, I'm not aware of any other devices with 098XPHWG4 date code being programmed successfully.

The MSP430 is programmed on-board with MSP-GANG programmer thru the JTAG connection.  It is powered by a 3.6V battery with 0.2V diode drop.  So, the supply voltage to MSP430 is about 3.4V.

The external power for the target is connected to pin 4 on the 14-pin JTAG connector per the note above.

Hi Charlie,

Everything you are doing sounds ok.

BTW, based on the photo, it looks like the LTC is actually 09AXPHW and not 098XPHWG4.  Our Quality dept found no reported issues with this lot/date code.

Hi Dennis,

Good catch.  Thanks for letting know about the error.

Do you have any idea or suggestion on what could be the root cause?

Hi Charlie,

It's difficult to say with the clues so far.

Do you have a 47k pull up resistor on the MSP430's REST pin?  And do you have a 1 to 2.2nF from this point to ground?

Hi Dennis,

I have 49.9k pull up resistor with 1nF cap to ground on the REST pin.

Hi Charlie,

Would you be able to remove one or two of the suspect devices? I’m checking to see if we can do a failure analysis on them.

Hi Dennis,

That sounds like a good idea.  I will contact our Engineering team to have those chips removed.

Please let me know once you confirm a FA can be done.

Hi Charlie,

Just to make sure we didn't overlook anything, is there anything else connected to the RST pin, diodes, other devices, etc., and would it be possible to share the portion of the schematic for this PCB?  I just need to look and confirm what is connected to the MSP430 pins.  You can send me Friend Invitation and share privately if you wish.

Hi Dennis,

Other than those two components, there is a 249 ohm series resistor going to JTAG connector pin 11.  I can share a copy of the schematic diagram with you.

Hi Charlie, 

Dennis is actually OOO. Can you send it to me via private message or via email? h-taffere@ti.com 

regards, 

Henok

Hi Henok,

I've sent the schematic to your email.

Regards,

Charlie

Hi Henok,

Please confirm if you have received my previous email with schematic.  Thanks!

Hi Charlie, 

Thanks for sending the schematic. 

A few things I want to check. Were you using a different firmware version for the time the gang has worked vs when it hasn't?

What page on user guide were you referencing for your schematic? 

regards, 

Henok

Hi Henok,

Thanks for confirming.

We were using the same firmware version throughout the whole time.  We did not update the programmer firmware.

 I'm not entirely clear about your question on our schematic.  Could you please explain?

Hi Charlie, 

Okay, FA might be the next step but let me first confirm with a teammate. 

I was asking which ti resources you were referring to for the JTAG connection, but considering all was well before I believe this is no longer necessary.

regards, 

Henok

Hi Charlie,

Can you tell me a little bit more about your application? Below are some questions that will help us figure out next steps:

• What is the voltage of your systems battery? Have you tried powering your board with the GANG programmer? 
• Does your application do any flash writes? 

Can you please send screenshots of the MSP GANG gui and the memory options view? Examples below:

Regards,

Evan

Hi Evan,

We are using 3.6V battery with diode voltage drop about 0.2V.  With that, the supply voltage to MSP430 is about 3.4V.  We have not tried to power from Gang programmer.  The main reason is that the VCC is not connected on pin 2 of the 14-pin connector.

Our application writes to Flash once every 24 hours.

I've included the screenshots per your request.

Regards,

Charlie

Hi Charlie,

Thanks for sharing that. It's interesting that even though the blank check fails the verify step is successful. 

Can you manually perform an erase (by clicking erase) and then do a read (by clicking read)?  The next step here is to determine what regions of memory are not properly erased. Please save and share the dumps from each devices as TI-TXT. 

If you could do this on a couple of devices that are having this issue then we can see if the failure is consistent across all the devices.

Regards,

Evan

P.S. Sorry for the long gap between messages, you reply got misplaces. I'll make sure to keep an eye out and get back to you ASAP!

Hi Evan,

No worries.  I'm glad you are able to review my settings.

I will share my test results as soon as I can.  We should have more devices returned for the same issue.

Regards,

Charlie 

Ok sounds good.

Hi Evan,

These are the TI-TXT files which I uploaded from couple our failed devices after I perform a erase and read afterward.  Please review and advise if any additional tests you'd like to do.

Regards,

Charlie

Target_m_9E.txtTarget_m_DE.txt

Hi Charlie,

Thanks for the posting that. Looks like the memory is entirely erased except for the info section (I think that's ok) and the flash segment around 0x8000. The two dumps that you posted had different contents in those regions. Questions:

• Is this unerased region where you application does in-application flash writes? If not is it code that is at this address?
• The contents of the two dumps you posted are different at 0x8000 is that expected? It is very strange that the devices pass the verification step despite the memory not getting erased.

I'm going to work internally to determine possible causes for a flash segments not getting successfully erased. 

Regards,

Evan

Regarding the blank check error: there are a couple other things to do to help determine the root cause:

1. Do you have access to an MSPFET? You can use uniflash to do an erase and a memory readback. If you do this do you still see memory regions that have not been erases?
2. The fact that the verification step passes is interesting. It implies that the devices were actually erased correctly. Do the devices function as expected in spite of the blank check error? 
3. How long are the cables that connect the gang to the device? Recommendation is 8in or less.
4. Flash memory erase can be fail if power is not reliable during the erase. You said your system is battery powered. Can you try powering the system from a bench supply to see if there any differences in behavior?

Regards,

Evan

Hi Evan,

I compared those two files I sent with a fully erased file.  Seems like the only un-erased sections are around 0x8000 and 0x8100.

Yes, our application does write to those two sections to answer your question.

Please let me know about any findings on your side.

Regards,

Charlie

Hi Charlie,

Did you get a chance to try running the sustem from a bench power supply?

Regards,

Evan

Hi Evan,

Yes, I did. It doesn't appear to make any difference as I'm still seeing the same issue.

I even powered with battery again and monitored the voltage.  It appears very stable at about 3.2V.

Regards,

Charlie

Hi Evan,

On a separate note, we did a test by repeating the process several times.  We found out that maybe 1 or 2 times out of 10 tries we were able to program successfully without failing blank check.

Do you have any idea?

Regards,

Charlie

Hi Charlie, 

I believe Evan is OOO. Let me take some time to look into this by asking our tools team. 

regards, 

Henok

Hi Charlie,

Charlie Lee said:

On a separate note, we did a test by repeating the process several times.  We found out that maybe 1 or 2 times out of 10 tries we were able to program successfully without failing blank check

This seems to indicate that there is something marginal about the programming flow. Given that the devices are functional and the process is occasional successful I don't believe there is anything wrong with the devices. Unfortunately it may be challenging to track down the root cause. I still believe you should try and determine whether:

1. The erase is successful, but the blank check reports a false failure, or:
2. The erase is unsuccessful

Things you can try that will help determine this:

1. run the JTAG at a slow speed. Does this change things?
2. Try programming a simple "blinky" type code example. 
3. Try a erasing/reading back multiple times. Do the contents of the unerased memory change?

Evan

Hi Evan,

I confirm that the erase is unsuccessful because I can see un-erased memory locations in the uploaded txt file.

I also did multiple erasing/reading back cycles and reviewed the contents.  The contents in the memory seem to change each time.

The segments which fail consistently is around 0x8000 to 0x81FF.  Our application does erase and write to these segments once every 24 hours.  I believe there's a minimum of 10,000 erase/write cycles for Flash segment and we may have few hundreds erase/write cycles in the worst case.  The Flash seems to fail prematurely somehow.

Regards,

Charlie

Ok understood.

If you are confident that flash at those memory locations is indeed compromised then we have to explore how that happened. 

Charlie Lee said:

we may have few hundreds erase/write cycles in the worst case

Is it possible that the application got trapped in loop of reading/writing those locations? How are you triggering this daily write?

Evan 

Evan,

The erase/write of Flash is triggered by our soft timer to occur every 24 hours.  Although we don't see any evidence that the application is stuck in a loop, nevertheless it's an interesting point from you.  I will take a closer look into this.

Charlie

Evan,

Not sure if you all are still working on this or not.  My name is Dustin Stubbs.  I work with Charlie and will be helping facilitate moving this forward.  As I understand it currently the next step is to get the defective MSP430 microcontrollers sent back to TI.  What is the path for doing that?  I have a total of 6 ready to go.  We really need to determine what happened to these.  Please let me know the path here.  

Dustin

Hi Dustin,

Thanks for the message. I am definitely still committed to helping you debug this. 

Unfortunately, I think a return of these devices won't give us much more insight. Based on all the evidence reported, the flash in question appears to have  worn out. Even if TI were to confirm able to confirm this, there isn't anything TI can do to determine why this happened. 

Before the devices leave the factory, the flash is thoroughly tested to confirm it meets datasheet functionality. It is highly unlikely that these devices failed at level well below (100's of writes) their specified write tolerance (minimum 10,000 writes). I have reached out to our quality team to see if this process has any history with pre-mature wear out just to make sure we have all the facts.

Overall, we haven't 100% ruled out there isn't an errant execution path that writes these locations in a tight loop.

Just curious, you mentioned 6 devices with this failure signature. What is the amount of working vs non-working devices?

Regards,

Evan

Evan,

Thanks for the response.  From the beginning of the project we have around 1000 devices that have been built.  This issue has never been observed.

I started a failure analysis request but have not submitted it yet.  We will get back to you on what we decide to do.  

Dustin  

Ok thanks for sharing that.

Our quality team responded saying this process doesn't have any history with premature flash wear out.

In the meantime I'm happy to help discuss debug strategies to see if there is anything we can learn from what we have. 

Some questions I have: Your system is battery powered, correct? What safeguards do you have to make sure the MSP430F2418 is always running within the datasheet recommended range? In order to write flash Vcc must be between 2.2V and 3.6V. Are you using SVS to put the device in a safe state during a power down event (ex: battery dies or is removed)? 

Regards,

Evan

Hi Evan,

Thaks for looking into this.

Our device is powered by 3.6V lithium battery.  There is an inline diode in place with 0.2V drop, so the Vcc on MSP430 is about 3.4V which is within the recommended range.  We even tried new battery and bench power supply to rule out any possibility of Vcc issue on those failed devices during programming.  The battery is always connected to our device and we do not power down at all.  The battery typically has about 3~5 years of lifetime.

Regards,

Charlie 

Charlie,

Ok makes sense. Without knowing to much about your application, I'm struggling to come up with more ideas for debug. Can you share a little more about your application and how you found these failures? If you'd prefer you can send me a private message.

Regards,

Evan