TMS320LF2407A: Serial Programming Issue

John,

            50% fallout is very high. How many devices have failed to program in this fashion? Can you provide the DPPM number? 

If there are absolutely no changes to either H/W or S/W since 2009, this shouldn’t be happening. Is there a possibility that something changed in the programming setup? For example, the PC that is used to program the device or even the OS on the PC (assuming it is a PC that is used to program)? Or a component on the PCB being sourced from a different supplier? Please provide details on your programming setup.

Are you able to program the failed devices by some other means, JTAG, for example? (assuming your board has a JTAG connector and you have a PC with CCSv3.3 or the Prg2xx utility).

John Puckett said:

This has occurred across multiple lots (information which I can provide if requested).

Please do provide that information.

John Puckett said:

We'd like Texas Instruments to provide some insight into whether this has been observed before, or if they have an idea what the cause may be.

No, we have not heard of a similar issue.

Would you mind sharing your schematics with me privately? You can do this by initiating a friendship request with me first. You can do so by choosing the "Request Friendship" option when you hover the cursor over my name.

Hareesh,

Friend request was sent. I'm waiting to hear back on confirmation regarding the programming PC, although I believe nothing has changed in that aspect of the setup either. I'll also follow up with some lot code information (waiting on that data).

Our product has a JTAG interface, and we are able to program the samples at the bench using it. However, the setup at our contract manufacturer is RS232 only.

John,

            I have accepted your invitation. 

This is a very mature device (>20+ years old). It is unlikely the device is exhibiting these issues with such a high fallout rate. Please answer my question about the # of devices that failed programming and the DPPM number.

John Puckett said:

Our product has a JTAG interface, and we are able to program the samples at the bench using it.

Are you saying the devices that failed programming using the serial port passed the same operation via JTAG? If so, that indicates that the Flash array itself is good. In theory, once could suspect the serial port, but as I said, this is a very mature device and we have shipped several millions.

Hareesh,

Much like the TI part, our product is very mature (2009) and unchanged. The programming steps involved have not changed since they were first implemented. I'm waiting to hear back on official fallout numbers.

Here are two lot codes from samples that have the issue (that we have in our lab currently):

CA-2BCE9RW

CA-32C1Q2W

We took one sample that had the issue, swapped in a known good DSP and the issue was not observed. The suspect DSP was then placed on separate different PCBs and the issue persisted in each case (issue stayed with the DSP).

That specific DSP has lot code CA-29AEVPW

John Puckett said:

The suspect DSP was then placed on separate different PCBs and the issue persisted in each case (issue stayed with the DSP).

Were you able to program the suspect DSP using JTAG?

John Puckett said:

That specific DSP has lot code CA-29AEVPW

Where do you buy DSPs from?

Hareesh,

We do have a JTAG port on our product, but it was mostly used for development purposes. We have not yet tried to program on JTAG with the suspect samples, but it is on our to-do list. I misspoke in an earlier post indicating we had successfully programmed with JTAG, my apologies.

Parts were purchased through Arrow Electronics.

John Puckett said:

I misspoke in an earlier post indicating we had successfully programmed with JTAG, my apologies.

It's OK. It would be an important step to determine if the Flash array has any issues. If you are able to program the Flash using JTAG alright, that leaves us with the below:

1. SCI port: The correct functionality of the SCI port can be easily tested by running an external loopback test (after shorting SCITX and SCIRX pins).
2. Boot-ROM: An easy method to check the BROM is to dump the contents as a hex file and compare it with a known-good part.

I looked at your schematics. Nothing appears to be terribly wrong.

Hareesh,

We're working through this (and other) testing now, and it will probably take us some time. I'd like to keep this thread open for now and report back on our findings as they evolve.

Understand. In the interim, I checked with our Quality folks if they have anything similar from other customers and they said “no”. The LOT trace codes you provided pertain to material manufactured in 2022 & 2023.

I frankly have to disagree.

We also have serial programming problems on 2407A (20% failure) since 11/2022 and reported them to our TI Field Application Engineer, with exact lot codes, schematics and error description.
2 different products are affected.
Software and Hardware was unchanged for years.

TI also said they have no other customers with this problem...

We (with great support from the german TI Field Application Engineer) finally changed our programming procedure to JTAG.

Stephan,

            I don’t have details about your host but I presume it is a PC. Assuming it is a PC, I can say the following: The host-side code was written over 20 years ago during the days of Win98 and when PCs used to have serial (and parallel) ports. You probably use some USB-to-Serial converter. There could be some boundary condition in the host+software that is manifesting in these failures.

John,

            You have rejected the resolution without providing a reason. If you merely wanted to keep this ticket open, I will do so.

If you were able to program the Flash via JTAG, that indicates the Flash is good. I already provided suggestions to test the serial port and the boot-ROM. Here again, if the serial port is bad, kernel, clear and erase wouldn’t have succeeded. If the boot-ROM had an issue, the transfer of the kernel wouldn’t have even started. I cannot suspect the RAM blocks either since they are the same blocks that are used in JTAG programming.

To give some more details:
For serial programming, we used a dedicated Windows XP with RS232 interface.
This PC did not change, but nevertheless we got programming errors with newer 2407A devices.
Neither TI nor we were able to solve them, so we decided to switch to JTAG programming.
JTAG interfaces for 240x are not supported by newer CCS or uniflash, so we would have to use CCS 3.3 which is only supported by Windows XP.
We finally use a Signum JTAGJet (USB) with Signum Flasher_C2000 Software that also works on Windows 10.

Hareesh,

My intentions were made clear in my previous post regarding our plan to work thru the testing (which we are currently doing) and then provide those results to update this thread. The issue is far from resolved.

Even if it turns out JTAG could be a solution, it is not likely something we can implement for our product and manufacturing processes.

John,

    Completely understand. Will keep this thread open. 

Hareesh,

No updates yet - just wanted to let you know this is still on-going (bit delayed due to the holiday).