Difficulty reconnecting after locking F28335

Steve,

The code security module (CSM) on the 2833x will disconnect the JTAG if it is connected and an access is made to secure memory.  A byproduct of this is when the device first powers up, before CCS is connected, the CSM may disable the JTAG.  To prevent that from occuring, there are two solutions:

1) use an emulator that supports wait-in-reset.  I believe the emulator you are using has this.  It uses the EMU0/EMU1 to hold the device at the reset vector until JTAG takes control.  (in SDconfig, emulator folder, make sure to click on the "Perform C28x style wait-in-reset" box)

2) use the "check boot mode" option in the boot loader that emulates a "wait-in-reset".   Basically this boot mode keeps the code from running into secure memory until you can connect JTAG.

For more information check the following sources:

TMS320x2833x, 2823x System Control and Interrupts Reference Guide (sprufb0):  http://www.ti.com/lit/sprufb0 and the TMS320x2833x, 2823x Boot Rom Reference Guide (spru963): http://www.ti.com/lit/spru963 .

Cheers

Lori

Thank you for the reply, Lori.

I ran SDConfig utility and checked the "wait-in-reset" option, though it didn't appear to change the situation.  The processor still runs the flashed and locked code but I can't connect to it with the emulator (this occurs on most every locked board, though I've occassionally "got lucky" and was able to unlock and reflash a board).  There was also an issue during production in that ~15% of the processors that the boards were built with had a similar problem in that I couldn't connect to them at all.  Once these processors were replaced, the boards worked fine and I could flash and execute code etc. ... until they were locked.

There was a supply issue at the time for the F28335 processors and so I'm not certain if there was a silicon change at the time, though I'm very familiar with the F2xxx family and could very likely be doing something wrong or there could be a boardline electrical condition on the board that some parts find more aggrevating than others, so there may be an additional board design and/or silicon rev. issue involved.

In SDConfig, when I run Configuration/Verify, I get:

** Using emulation application from directory c:\ccstudio_v3.3\drivers
** Checking for a valid emulator/eZdsp

  $$ You are connected to:
  $$ EmuProductName=XDS510USB
  $$ EmuPortAddr=0x510
  $$ EmuPortMode=USB
  $$ ProductId=510
  $$ ProductVersion=84

If I run the Emulator/Test, I get an additional JTAG error:

 ** Emulator Scan Test

ERROR >> JTAG IR scan test failed

An additional note:  I don't particularly care about unlocking the processor, if there's just a way to reprogram the processor that doesn't require replacing it.

Alternately, is there a way to protect the software from being viewed without locking the JTAG?  We just want to keep the code from being copied, but don't particularly care about disabling the JTAG.

I received a reply from Tim Love and it looks like it was the problem - I haven't fully verified that everything else is working ok, but I was able to unlock and reflash one of the processors by pulling GPIO84 low to disable it from booting from flash.  After that I could connect, unlock and reflash the processor.