- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Dear all,
I have some questions about DCSM and ECSL security features of the above DSP.
All questions are related to ISP (In System Programming) of TMS320 with non-volatile data programmed both in Flash and User OTP areas.
At this moment I'm doing some tests by using Uniflash and I would like to know how to appreciate the effect of DCSM and ECSL security features on emulator connections.
I can state that after programming a factory shipped device some user OTP have been written.
In particular:
- Z1OTP_EXEONLYRAM
- B0_Z1OTP_EXEONLYSECT
- Z1OTP_GRABRAM
- B0_Z1OTP_GRABSECT
- Z1OTP_CSMPSWD0
- Z1OTP_CSMPSWD1
- Z1OTP_CSMPWD2
- Z1OTP_CSMPWD3
The CSM password is fully different from the TI pre-programmed one and LINKPOINTERs are the default ones so it is located at address 0x78028.
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?
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?
In that case, if I try to connect my XDS100v2 to the target by providing the correct password I can connect the emulator and Erase, Blankcheck, Read and Program again the flash contents.
3) Is that because Uniflash performs the ECSL Password Match Flow?
Furthermore, if I read the User OTP area contents all data are 0x0000 (see below) except for the CSMPWD, I suppose because the Z1OTP_PSWDLOCK has been left untouched in my tests.
4) What causes that, DCSM protection?
5) Is there a way to read "protected" values?
Maybe downloading and executing from RAM a small JTAG based custom bootloader?
I ask this questions because I've been asked to re-program a DCSM and ECSL protected device with industrial programming tool by using JTAG interface.
Since I will have to add some code to programminmg algorithm to manage this, I need to fully understood the system....
Best regards,
Federico
Hi Federico,
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.
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.
3) Is that because Uniflash performs the ECSL Password Match Flow?
I shall get back to you on this from expert opinion
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.
5) Is there a way to read "protected" values?
i shall get back after expert opinins.
Thanks
Aswin
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?
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.
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
Dear Vivek,
Yes, it performs CSM match flow (which includes ECSL password match flow). Hence you are able to connect and perform flash operations.
GOT IT.
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?
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
