C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled.

Phil,

Based on your description, I believe your device is locked (or) secure.

ECSL (Emulation Code Security Logic) in F2808 will trip an emulator connection to prevent unauthorized users from stepping through secure code. Any code access to secure memory while the emulator is trying to connect (or) connected will trip the emulator connection. This error gets reported in CCS as shown below:-

"C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled."

I would suggest you to set device boot mode pins to "boot to SCI option" and then try to connect to the device. Boot to SCI will prevent flash access allowing you to connect to device through emulator. Once connected, you can unlock the device by entering password in KEY registers (0xAE0 - 0xAE7)

Hope this helps you get going...

Regards,

Manoj

 

Manoj,

I agree that your assessment is correct that the device is locked. That said, I'm not sure I follow you completely on how to get past that. I found the TMS320F2808 (plus other devices) Data Manual on the TI website. There is a Boot Mode Selection table (Table 3-7) that lists Boot Modes. Are you saying the SCI-A boot is the option I want and that I have to force GPIO18 to "1" (via a pull-up resistor or directly to power?), GPIO29 to "1" (via a pull-up resistor or directly to power?), and GPIO34 to "0" tied to ground? These pins are all tied to other devices but I think I can manage it. If that is correct, are these pins sampled at power up (meaning I need to power cycle the device) or just when the debugger is started?

I also a thread where it sounds like you can do this via a code change or in CCS settings. Is that true? Where can I find details on that? I did look through the Debug Configurations section but didn't see anything there.

Phil

 

Manoj,

I have a little more information for you. I acquired a TI C200 experimenter kit and discovered something. I could go into debug and load the flash. I then got the following error:

C28xx: AutoRun: Target not run as breakpoint could not be set: Error enabling this function: ANA_ENABLE Register write failed

After that, I tried launching the debugger again but got the same Device is Locked message I got with my hardware. So I began to think the original problem is a SW setting not hardware. I erased the DSP's flash on my hardware. After that, I was able to get the debugger to load my project into clean flash.

So, why isn't the debugger erasing the flash first? If it is a security thing, why did I not get the chance to enter a password?

At this point I'm thinking my project settings are off in CCS. Recall that I inherited source code but no project files (although know it was done in version 3.3).

I hope that extra information is helpful. Thanks.

Phil Dilmore 

 

 

 

Phil,

Yes, I did want you to set GPIO18 = 1, GPIO29 = 1, GPIO34 = 0 to select SCI-A boot option. On device powerup, boot rom checks these pins to determine desired boot mode.

In flash boot mode, boot rom executes and jump to flash which is secure. Any secure memory access when the emulator is connected (or) trying to connect will trip the emulator because of ECSL.

My main objective here is preventing CPU access to any secure memory to avoid ECSL trip.

In SCI boot mode, after configuring SCI pins and peripheral waits in an infinite loop till autobaud is locked (So, no access to secure memory) , this gives us enough time for us to connect to device using emulator. Once, you connect to the device, you can easy unlock the flash by entering password in KEY registers.

Regards,

Manoj

Manoj,

It doesn't seem like you saw the additional information I posted regarding erasing the flash first starting with "I have a little more information....". Please see that posting.

Also, there are two other reasons I question whether we are going down the right track.

1. My Code Composer indicates "unlicensed". I did check on the licenses which seems right to me. I also searched on the E2E sight and found a number of replies to the same question indicating it wasn't a problem. I did start a separate thread on that topic and the initial response was that unlicensed CCS won't operate the debugger properly.
2. In the source code I inherited, I found the following snippet of code in MAIN.c: 

//    As supplied, this project is configured for "boot to SARAM"
//    operation.  The 280x Boot Mode table is shown below. 
//    For information on configuring the boot mode of an eZdsp,
//    please refer to the documentation included with the eZdsp, 
//
//       Boot      GPIO18     GPIO29    GPIO34
//       Mode      SPICLKA    SCITXDA
//                 SCITXB
//       -------------------------------------
//       Flash       1          1        1
//       SCI-A       1          1        0
//       SPI-A       1          0        1
//       I2C-A       1          0        0
//       ECAN-A      0          1        1       
//       SARAM       0          1        0  <- "boot to SARAM"
//       OTP         0          0        1
//       I/0         0          0        0

The original designer says it should boot from SARAM.

So, that said I'm not sure trying to boot from SCI-A is going to fix this issue.

I'm also not clear on running the debugger. Does it always try to reload the flash? Why is it not erasing first? Where are the settings to erase, program, verify in CCS?

Phil

Manoj,

I seem to have things working nicely as far as getting the debugger up and running. I found the password in the code and entered it in both the Debug >> Flash Setting and in the .gel file I'm using. When I launch the debugger it goes in and erases the flash, then loads and comes up ready to run. I no longer get Device Locked or even the ANA_ENABLE Register Write error I was seeing. So setting the password as you suggested and turning off the auto run option you also suggested got me past the original problems I was having. Thank you for your help.

Phil

Dear Manoj. 

My ezdsp also locked.. 

Can you please explain me how you recovered from the problem.. 

Jithin,

Do you know the password (or) do you have the COFF (.out) programmed into device? If you don't have either of these, you can't unlock the device. Your only option is to replace the part.

Regards,
Manoj