TMS320F28379D: problem with programming OTP_PSWDLOCK

Hi Matthew,

Z1_OTP_PSWDLOCK is at 0x78010 (64bits data is 0x0FFF 0x0000 0xFFFF 0xFFFF, and corresponding ECC found at 0x1071002 is 0xED73.
Indeed those fields were programmed.

MatthewPate said:

Since you know the password you should be able to increment the Zone Select Pointer to a new fully erased location.

I thought about it and checked already. Unfortunatelly PSWDLOCK is at constant location (i.e. 0x78010). So change of Zone Select Pointer doesn't solve that.

I have another idea that is based on ECC collision. My goal is to lock security password, so in order to do that I need to program into PSWDLOCK a value where its 4 lower bits are different than 0b1111. I have still 8 ones at bits 11-4 that I can manipulate. At the same time ECC is 8 bits long. Unless I am very unlucky there is another PSWDLOCK that has the same ECC and fulfills my requirement. 

When I find the value I will use regular CCS to program it. So far I am avoiding to write the code.

What do you thing, will it work?

Regards,

Piotr Romaniuk

I found that value 0x0000037B generates the same ECC as 0x00000FFF for PSWDLOCK as well as CRCLOCK.

I successfully programmed it via CCS debug perspective and it works as OTP contents lock.

May I ask you for confirmation that:

1. value of PSWDLOCK bits 31-4 are irrelevant for CPU functionality and have no side effects

2. the same for CRCLOCK

3. value 0x37B is enough to satisfy LOCK conditions for both PSWD and LOCK

4. value of OTP words 0x7801C and 0x7801D are irrelevant (those two words are remaining part of 64 bits for Z1_OTP_BOOTCTRL and influence its ECC).

Regards,

Piotr Romaniuk

Piotr,

Please give me an additional day to respond back to you.

Best,
Matthew

Hi Matthew,

Ok.

For BOOTCTRL where 0xFFFFFFFF and ECC=7F were unintentionaly programmed, it is harder but not hopeless.

I need BOOTCTRL=0000 0B5A. Unfortunatelly, there is no value of other 32bits part that would generate ECC=7F.

However, four zeros at the beginning mean that BOOTPIN1 and BOOTPIN0 are default.

Without any change of behaviour, the pins can be also specified by its GPIO numbers, the default are:

  BOOTPIN1=GPIO72 and BOOTPIN0=GPIO84,

so BOOTCTRL=49550B5A. If this value is required, 64bits part equal to 49550B5A.00010020 has ECC=7F.

Hence my question 4 in my previous post.

Regards,

Piotr Romaniuk

Thank you for confirmation and suggestion. Unfortunatelly Z2_BOOTCTRL is also programmed (with FFs), so question 4. is still important for me.

Regards,

Piotr Romaniuk

Hi Piotr,

The upper 16 bits of Z1_BOOTCTRL control the bootmode select pins, so these values are relevant. To use Get Boot mode/Boot to flash, both boot mode select pins need to be a 1. I would recommend using the DCSM Tool in SysConfig to test different boot mode pin selections as not all of the GPIOs can be used as boot mode select pins and you can quickly see the value of Z1_BOOTCTRL based on the boot mode select pins that  you configure. Let me know if you need any assistance to do this.

If you can't find a valid configuration for your boot mode select pins that will program a valid ECC value, can you not just use a new part for your DCSM configuration? I can provide some guidance to avoid bricking a new part if you provide some details on how you originally programmed the device you're currently using.

Thank you,

Luke

Hi Luke,

Luke Jones said:

The upper 16 bits of Z1_BOOTCTRL

My question was about other 32 bits (words located at 0x7801C and 0x781D) that form together with Z1_BOOTCTRL (0x7801E and 0x7801F) atomic 64bits part that has common ECC. The question is not about how to set the register (i.e. the value) but how to "repair" unintentionaly programmed FFs in the register and if the proposed method is safe, i.e. has no side effects.

Regards,

Piotr Romaniuk