TMS320F28062 unlock CSM

Timothy,

I believe you are talking about unlock_csm function available in F2806x.gel file. In that case, if the user has a custom password they can enter them in KEY register as highlighted below to unlock the device using gel functions. The dummy reads of the password location unlock only when the password is all 0xFFFF's. When you receive the parts from TI factory, the device is unlock state and the password locations are all 0xFFFF's.

hotmenu Unlock_CSM()

{
/* Perform dummy reads of the password locations */
XAR0 = *0x3F7FF8;
XAR0 = *0x3F7FF9;
XAR0 = *0x3F7FFA;
XAR0 = *0x3F7FFB;
XAR0 = *0x3F7FFC;
XAR0 = *0x3F7FFD;
XAR0 = *0x3F7FFE;
XAR0 = *0x3F7FFF;

/* Write passwords to the KEY registers. 0xFFFF's are dummy passwords.
User should replace them with the correct password for their DSP */
*0xAE0 = 0xFFFF;
*0xAE1 = 0xFFFF;
*0xAE2 = 0xFFFF;
*0xAE3 = 0xFFFF;
*0xAE4 = 0xFFFF;
*0xAE5 = 0xFFFF;
*0xAE6 = 0xFFFF;
*0xAE7 = 0xFFFF;
}

Regards,

Manoj

Greetings Tim,

Are the passwords actually programmed, or have they been left as 0xFFFF?  If 0xFFFF, then the bootload in the boot ROM will unlock the device after reset.  Perhaps this is what you are observing.  The device is already unlocked.

If the passwords are actually programmed (to non-0xFFFF or non-0x0000) and the device is reset, reading from the CSMKEY registers and writing what's been read back to the CSMKEY registers does nothing (actually, it never does anything).

Regards,

David

Just to add what Manoj and David mentioned, the statement in TRM "Any read of the CSM password would yield 0x0000 until the device is unlocked." is for PASSWORD locations in Flash and not for CSMKEY register. If user has written the passwords in CSMKEY register and not cleared them, then subsequent reads to these registers will return the value written.

Regards,

Vivek Singh

First, a correction to what I told you. The device is correctly reading from the CSL_PWL location not the CSMKEY as was stated earlier. Other pertinent facts:

1. The passwords are programmed. The unlock_csm function we were referring to was our own that reads the password from the password locations and then writes these values to the KEY registers to unlock the device rather than writing hardcoded values to the KEY registers.

2. The snippet that we sent is executing from flash (starting at 0x3E8000) and the stack is in L0-L2 DPSARAM (0x8000)

F28062.cmd file snippet:

   DRAML0      : origin = 0x008180, length = 0x000E80     /* on-chip RAM block L0 */

...

   .stack              : > DRAML0 (HIGH) PAGE = 1

We also tested the snippet with the password at all F's and "force locked" the device right before the call to Device_cal and it does the same thing, as expected. We mentioned that it locks up but we think it may be stuck in a reset loop.

To summarize our two outstanding questions:

1. Why is an unlock required to perform a Device_cal?

2. Performing a "dummy read" on the password locations returns the password and not 0x0000 as stated in the manual?

Thanks for all your help on this, and Best Regards,

Tim Starr on behalf of DS@PM

Hi Timothy,

2. Performing a "dummy read" on the password locations returns the password and not 0x0000 as stated in the manual?

If you are running the unlock_csm() function from secure memory (which means it's secure code) then it'll be able to read the passwords value from CSM_PWL location correctly.

The statement in manual is wrt device security initialization which is done from non-secure memory (e.g. BootROM code). But I agree that it should have been mentioned explicitly to avoid confusion. We'll look on how this can be updated in future release of document.

We'll have someone else to answer your question on "Device_cal()".

Regards,

Vivek Singh

Hi,

On below question -

1. Why is an unlock required to perform a Device_cal?

Please check if the stack is located in secure memory which could cause such issue.

Regards,

Vivek Singh