SM320F28335PTPMEP Microcontroller Locked

Anand,

It appears you have inadvertently locked the part. This could happen due to a few reasons:

1. If you are using the header files, did you include the DSP2833x_CSMPasswords.asm file in your project? By default, this file comes with a password of all F's (0xFFFF). This would ensure the passwords are always written with FFFF and hence the device never locks.

2. If there is a black-out of brownout  condition during programming operation, that could cause corrupt values to be written to the password locations and inadvertently lock the part. It is important you use a robust power supply that is capable of meeting the transient load needs during flash programming.

3. Did you look at the .map file for your project  to see if some random data got written in the password locations?

Anand,

To your other question -

And how to come out from this mode?

If device is locked and password is not known or passwords values were programmed with value 0x0 (either due to random data or due to interruption during programming) then part can not be unlocked and only option is to replace the part.

Regards,

Vivek Singh

Hi,

Thanks Hareesh and vivek for your reply.

 I will provide you more details about my problem.

I have two Controllers (DSP1 and DSP2), JTAG connected in daisy chain mode (TDO of DSP1 connected to TDI of DSP2). Everyday, we do flash at least 50 times (including boot flash section A and B). Same code is being loaded for DSP1 and DSP2. It works for some days and DSP1 goes to lock state every time but not the DSP2. Keeping GPIO 84,85,86, 87 to 0010,I can able to access DSP2 and do program multiple times with no issue. But every time only DSP1 goes to lock state. Remember code loaded in DSP1 and DSP2 are both same. Using uniflash, we verified CSM location, it was written with 0000 in DSP1 and FFFF in DSP2. It clearly shows, unfortunately 0000 is written to lock the device. But this was not done intentionally. As per code, we are not accessing CSM location. Don't know, how this was happened. Since same code is loaded in the DSP2, why this is not going to lock mode. I have 10 boards like this. In all the board, I am facing same problem (DSP1 going bad, DSP2 is good). This is very critical problem for me.

Even after replacing DSP1 with new one. It works for some time(2-3 days) and again going to lock mode.

@ Vivek, - "0x0 (either due to random data or due to interruption during programming)"

After replaced device, we started observing closely. In one of the board, while flashing in DSP2 using emulator (in Sector A, B, C and D), the application is hanged for some time and back to normal. Again we flashed it, and successfully flashed both DSP1 and DSP2. This time, again DSP1 is went to lock state. Here question is, while flashing DSP2, JTAG application is hanged (We can consider this as interruption) but not during flashing DSP1. But Why DSP1 is went to lock state, not DSP2?

I am using SDS560V2, Blackhawk System Trace JTAG emulator for program loading. And my PC operating system is Windows. Is it something wrong with operating system and emulator? I tried with different emulator with same part number, still getting same issue.

There is no possibility of power interruption or voltage spike in the board. I have monitored, everything is normal.

I couldn't able to figure out the root cause.

Hi Anand,

Thank you for providing a detailed description of the setup and issue you are facing. Sorry to hear that you have 10 boards with parts in LOCKED state.

You mentioned that this issue happens whenever DSP2 programming sequence hangs for some time. What exactly you mean by this hang condition and how do you know that this condition has occurred? Following are some additional questions -

• Are you using CCS Flash plug-in to program the devices or using Flash API?
• When DSP2 is getting program, what is the state of DSP1? Is it in HALT state or running state. And if you are using the Flash API to program the part, do you clear the API code from the RAM after programming is done or it stay there.
• Both the DSP share same power supply or both have their own power supply. Do you see any dip in the supply voltage during the program operation?

Since TDO of DSP1 is driving TDI of DSP2, I am just wondering if sometime it's drawing lot's of current from DSP1 which is causing this issue.

Regards,

Vivek Singh