TMS320F2808: TMS320 Devices get locked accidently, reason is unknown - reopen

Hi Jan,

Sorry for the delay and the prior post getting locked.

I believe there is additional information on this issue now, but I will need to consolidate the info and get back to you. I've been somewhat out of the loop on the discussion.

Best,

Kevin

The Reserved bits are meant for TI internal testing. The values of some bits are not static and change dynamically based on CPU and CSM operations

Thanks, but you can not provide/publish the bits meaning? Nor if one or multiple bits allow for recognizing a locking procedure? Or the reason for that? Jan

There is no valuable information in those reserved bits to debug the issue and we don’t publish details of reserved bits. 

It could be that the device got accidentally locked. This could happen when there is a brownout or blackout during programming. i.e. even though your application didn't have passwords, the brownout could have resulted in writing junk values to the password locations unintentionally securing your device. Unfortunately, there is no way to recover from this situation since you don't know what values got programmed into the password locations in flash. Things to ensure: (i) Ensure that flash is erased before commencing programming. i.e. waiting for the erase time mentioned in the datasheet before commencing programming. (ii) Ensure that the device is not "current starved" during erase/program operation

Hi Hareesh,

many thanks for the answer! Is there a way to detect a brownout or blackout situation for sure?

Best Regards

Jan

Monitoring for those conditions need to be done externally. Just to put things in perspective, this is a fairly mature device (over 15 years old; the underlying flash technology, even older). The flash programming algorithms are pretty stable at this point (please ensure you are using the most recent version of the API; check the TI website). Typically, we have been able to root-cause programming issues to one of the following reasons: (i) Some kind of interruption to the erase/program (E/P) process – this can potentially leave the password locations with some random values. (ii) Current-starving the device during E/P.

Thank you very much for the clarification! Do you have an idea how to recognize/track down one of the explained reasons (i) oder (ii)? The boards that we talk about are very complex, they need several voltages to be powered and the problem occurs not too often. What it makes spcific is that the boards are used in safety environment, they are very expensive and the test environment is a quite complex rack-setup...

Sorry, I didn't understand what you mean by "oder". If you could privately share more details of the programming setup, schematics etc, I might be able to help. A friendship request would facilitate that.