TMS320F280021: Re-program a DCSM (and ECSL) protected TMS320F28002x

Hi Federico,

Federico Devescovi said:

1) Being all its components of CSM password different from the default ones, if I have fully understood the TRM, both DCSM and ECSL are engaged, aren't they?

Yes both are engaged, but you still can have DCSM enabled and have the provision to disable ECSL by providing the lower 64 bit password into the CSMKEY register.

Federico Devescovi said:

2) I can see that because after powering off/on the device there is no chance to connect anymore the XDS100v2 to the target unless I use GPIO24 to boot in Wait Boot Mode, isn't it?

During the initial powerinf off/on the device, the emulator takes some time to take control over the CPU. Meantime, the CPU will start running and may execute an instruction that perform access to protected ECSL area, and if CPU is halted when PC is pointing to a secure location, which will trip ECSL. However, you can use the Wait boot mode option  to over come this.

Federico Devescovi said:

3) Is that because Uniflash performs the ECSL Password Match Flow?

I shall get back to you on this from expert opinion

Federico Devescovi said:

4) What causes that, DCSM protection?

If a zone is secure, its USER OTP contents (including CSM passwords) can be read only if the zone is unlocked using the password match flow.

Federico Devescovi said:

5) Is there a way to read "protected" values?

i shall get back after expert opinins.

Thanks

Aswin

Aswin P said:

Yes both are engaged, but you still can have DCSM enabled and have the provision to disable ECSL by providing the lower 64 bit password into the CSMKEY register.

OK, GOT IT. If I just perform the CSM password match flow, the ECSL password match flow is also included or they are two totally separated flows? 

Aswin P said:

During the initial powerinf off/on the device, the emulator takes some time to take control over the CPU. Meantime, the CPU will start running and may execute an instruction that perform access to protected ECSL area, and if CPU is halted when PC is pointing to a secure location, which will trip ECSL. However, you can use the Wait boot mode option  to over come this.

OK, GOT IT.

Both GPIO24 and GPIO32 must be available (and of course nXRS) to enter this particular Wait Boot Mode.

Aswin P said:

If a zone is secure, its USER OTP contents (including CSM passwords) can be read only if the zone is unlocked using the password match flow.

I can confirm (just tried with Uniflash) that CSM passwords are also hidden, i.e. 0x0000, only if Z1OTP_PSWDLOCK[3:0] has been previously programmed with everything but 0b1111. In case they are left untouched the CSM passwords can be read (the picture I attached at the beginning of this post confirms that).

Picture above is taken from Uniflash after having Unlocked the device. If I try to read again, let' s say sector0 that, according to B0_Z1OTP_GRABSECT, belongs to Zone1, I still read 0x0000. This makes me think that Uniflash just performs ECSL password match flow, otherwise, as the TRM states:

I also add the following information which can help you. Programmed value of B0_Z1OTP_EXEONLYSECT is 0x0000FFFF.

So said, why Uniflash still reads 0x0000 (see below)?

The answer to this additional question, in my opinion, will probably give an answer to questions 3) and 5).

 Thanks again for your kind reply.

Regards,

Federico

Hi,

Federico Devescovi said:

3) Is that because Uniflash performs the ECSL Password Match Flow?

Yes, it performs CSM match flow (which includes ECSL password match flow). Hence you are able to connect and perform flash operations.

Federico Devescovi said:

5) Is there a way to read "protected" values?

If you have provided correct 128bit password then you should be able to see all protected values. Have you done that ? Or only provided 64bit password (ECSL Password) ?

Regards,

Vivek Singh

Dear Vivek,

Vivek Singh said:

Yes, it performs CSM match flow (which includes ECSL password match flow). Hence you are able to connect and perform flash operations.

GOT IT.

Vivek Singh said:

If you have provided correct 128bit password then you should be able to see all protected values. Have you done that ? Or only provided 64bit password (ECSL Password) ?

Yes, I did press UNLOCK button in Uniflash GUI with the whole password provided. But I still see 0x0000 for all secured data according to B0_Z1OTP_GRABSECT.

It is very strange because it goes against what TRM states.

Do you want me to double check this by trying with another factory shipped DSP?

Can you provide the GRABSECT settings for Zone1/Zone2 for the Flash sectors?

Yes of course.

B0_Z1OTP_EXEONLYSECT is 0x0000FFFF

B0_Z1OTP_GRABSECT is 0xAAAAAA65

Zone 2 has been left untouched.

Dear Vivek,

I'm sure I didn't unlock Zone2. Tomorrow I'll try and let you know. 

Dear Vivek,

I have tried to press UNLOCK button for both Zone1 and Zone2 but I still see 0x0000 (for both protected Flash and OTP).

This means zones are not getting unlocked. Can you check the value of Z1_CR/Z2_CR in register view and let me know.

I would also suggest to try this via CCS Flash plug-in GUI. 

Regards,

Vivek Singh

Dear Vivek,

I tried to read the value of Z1_CR register at address 0x5F019 after connecting my XDS100v2 to my CSL (and no ECSL) locked device.

Register value is:

And that's what I expect to see.

Then I press UNLOCK button for Zone1 and I got:

If then I read again Z1_CR register value I fonud the same value as before (0x0040).

The problem could be that Uniflash does again DCSM Initialization Start ... providing default password for Zone1 that does't match the correct one. 

Furthermore I've checked the f280021.gel file and the function SetupDCSM() uses default password values to unlock.

And this will lock again devices secured resources.

It makes sense, doesn't it?

Regards,

Federico

Federico,

That should not happen. 

Vivek Singh said:

I would also suggest to try this via CCS Flash plug-in GUI. 

Can you try this on CCS and see if it works ?

Regards,

Vivek Singh

Federico,

Glad this you got it working. SetupDCSM() function should  not be called after unlock operation. After unlock, are you doing some other operation which makes it secure ? 

Regards,

Vivek Singh

Dear Vivek,

after UNLOCK I go to read menu and I read OTP or Flash contents but I see that the Uniflash GUI still calls SetupDCSM() because I see the Gel_TextOut() output on terminal.

Since the original SetupDCSM() has default passwords for each zone I think that this causes 0x0000 to be read again.

Unless Uniflash internally replaces the default password with the just provided right password, but I dont know if it does it.

So what I do is UNLOCK (successfully) + READ (Flash, OTP,...).  

I didn't try with CCS because I'm not used to deal with Flash plug-in GUI.

Regards,

Federico

Ok, thanks. I have sent this query to our Uniflash team. Will update you on our finding.

Vivek Singh

Federico,

Can you make sure that the "Remain Connected after operations" option is on? This option is available under the core name on the top-right corner, and it makes sure that the core remains connected after the unlock operation. If it disconnects and connects again between the memory read, the device will lock up again.

Please let me know if this setting works for you case.

Thanks,

Ricky