TMS320F2812: Code Security Password Locked Prior to Programming

Mark,

1. Are the two devices on the same JTAG chain (i.e. daisy-chained)? Or do they have independent JTAG connection?
2. How did you determine that the device is “locked”?
3. What JTAG debug probe ("emulator") do you use?
4. If it is XDS-100 class or later, can you try more recent versions of CCS like CCSv12.5?
5. 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

1.  Both devices use the same JTAG header.

2.  Here's an example screenshot of attempting to unlock one of the DSPs.

3. The CCS references the emulator as SD510usb.  Our documentation refers to the cable as "C2000 Spectrum Digital Programmer", I do not have access to the programmer today.  I can follow up on this Monday.

4.  I don't believe the emulator is an XDS-100 class or later.  Are you thinking this is the issue?

5.  I sent a friendship request earlier.  I will send the DSP portion of the schematic.

Mark Halpin said:

1.  Both devices use the same JTAG header.

OK, both devices are daisy-chained then. 

Mark Halpin said:

2.  Here's an example screenshot of attempting to unlock one of the DSPs.

Is it always the same DSP that appears to be locked?

Mark Halpin said:

3. The CCS references the emulator as SD510usb. 

OK, it is likely you have a XDS510USB or XDS510USB+ or XDS510USB-LC. Just FYI, Spectrum digital is not in business anymore, so there is no support should you have any emulator issues.

Mark Halpin said:

4.  I don't believe the emulator is an XDS-100 class or later.  Are you thinking this is the issue?

Not necessarily. However, having a XDS100 or XDS110 or XDS200 debug probe means you can use the most recent (Eclipse-based) CCS versions  like v12.5. These probes are very inexpensive. XDS110 is just $135. Note that  Eclipse-based CCS is free to download. CCSv3.3 is not free. It would be a good idea to upgrade, since support for CCSv3.3 is deprecated.

1.  Both devices use the same JTAG header.

OK, both devices are daisy-chained then. 

Mark Halpin said:

2.  Here's an example screenshot of attempting to unlock one of the DSPs.

Is it always the same DSP that appears to be locked?

It is not always the same DSP that appears to be locked.

Mark Halpin said:

3. The CCS references the emulator as SD510usb. 

OK, it is likely you have a XDS510USB or XDS510USB+ or XDS510USB-LC. Just FYI, Spectrum digital is not in business anymore, so there is no support should you have any emulator issues.

Mark Halpin said:

4.  I don't believe the emulator is an XDS-100 class or later.  Are you thinking this is the issue?

Not necessarily. However, having a XDS100 or XDS110 or XDS200 debug probe means you can use the most recent (Eclipse-based) CCS versions  like v12.5. These probes are very inexpensive. XDS110 is just $135. Note that  Eclipse-based CCS is free to download. CCSv3.3 is not free. It would be a good idea to upgrade, since support for CCSv3.3 is deprecated.

Would an upgrade help diagnose this issue?

I reviewed your schematics. The datasheet recommends a 2.2K pull-down on the -TRST pin. Is the PD on a sheet you did not send to me?

Mark Halpin said:

Would an upgrade help diagnose this issue?

May be. However, if this is an existing design that you were able to program both devices successfully in the past, the problem may be elsewhere.

Did you observe this problem after attempting to program the Flash or did you see this in the very first attempt wherein you merely tried to connect to the devices?

I do not see a pull-down on the TRSTn pin.  Will not having this pull-down lock out the CSM?

Lock out of the code security is a very recent issue.  We have connected and successfully programmed hundreds of boards with the set-up we are currently using.

This problem is only happening after connecting to the specific DSP.  We find DSP1 locked up after connection (not programming).  Since our process is always in the same order, we sometimes find DSP2 locked after connection (but not programming DSP2) this is after programming DSP1.  We've not tried connecting to DSP2 first ever.

Mark Halpin said:

I do not see a pull-down on the TRSTn pin.  Will not having this pull-down lock out the CSM?

Not necessarily. However, a PD on this pin is highly recommended. Without a strong external PD, this pin can become vulnerable to noise, which could potentially put the device in some indeterminate state. Unintentional locking is also a possibility.

Mark Halpin said:

Lock out of the code security is a very recent issue.  We have connected and successfully programmed hundreds of boards with the set-up we are currently using.

OK. This means there could be some marginality in the design.

Mark Halpin said:

This problem is only happening after connecting to the specific DSP.  We find DSP1 locked up after connection (not programming).  Since our process is always in the same order, we sometimes find DSP2 locked after connection (but not programming DSP2) this is after programming DSP1.  We've not tried connecting to DSP2 first ever.

In how many boards do you see this issue?

6 boards showed the same issue on the same date.  I plan to retest these boards to see if possibly both DSPs are locked up.  It was not stated in the test results which DSPs were locked on each board.

OK. In the past, we have seen current-starving the device during the Erase/Program operation can corrupt the password locations inadvertently locking the device. We have seen this happening with docking stations where the PC's USB port was used as the sole power source (the datasheet cautions against this). Another thing to look into is whether anything changed. For example, any component on the board, the PC used to program the devices, the tool (H/W or S/W) used in programming. Just about anything. This is a 20+ year old device. The chip and the Flash algos are all pretty mature at this point and stable.

I was aware through this forum of the locking issues related to Erase/Program of the DSP.  I have not found any instances of locking upon connection to the chip prior to programming.  You have given me some things to look for.  Thank you.

OK. Do let me know what you find. Here is a very informative link.

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html#cti-20-pin-header-information