TMS320F28035: Password processing within secure memory

Hi Steven,

I'll need some time to review the CSM chapter to answer this. I'll try to get back to you by tomorrow.

Thank you,

Luke

Hi Steven,

From my understanding of the CSM chapter these steps should work. Let me know if this does not work for you.

Thank you,

Luke

Hello Luke,

Thank you for your reply. I added one more step to make this work, but I don't know why.
I must unsecure the MCU before erasing Sector A; otherwise, the resecure of the MCU will fail.

Step 1. Read the password and store it in RAM
Step 2. Unsecure the MCU with the password obtained from Step 1
Step 3. Erase Sector A
Step 4. Write Sector A with the new program code
Step 5. Write the password (get from Step 1)
Step 6. Resecure the MCU

Does the technical reference have any information or examples about this?
I can only find the C code example for unsecuring and resecuring the MCU.

Best regards.

When the resecure of the MCU fails, what do you observe?

Hello Luke,

Resecure failed means that the MCU stays unsecured.

Without Step 2, it works when using the debugger via JTAG.
(I observed step by step, except for the last step, because resecuring the MCU will disconnect the debugger.)
However, when I run these steps without the debugger, the MCU stays unsecured, and the password resets 0xFF...FF.
(Process Finish -> Power Off -> Reconnect Debugger via JTAG -> Power On -> CCS)

By adding Step 2, it works without the debugger.
The MCU stays secure, and the password is correct.

Okay, it seems like the erase works when the debugger is disconnected but subsequently writing the the password does not work.

I expect that the CSM is actually unlocked whenever the debugger is disconnected. Otherwise the debugger would be disconnected during your step-by-step test in secure memory.

I will check with our other CSM experts whether erasing is successful when the CSM is locked but writing to the password locations with a locked CSM is unsuccessful.

Hi Steven,

My team confirmed the erase function erases the CSM passwords. I will need more time to look into this further. Let me know if this is an urgent issue.

Thank you,

Luke

Hello Luke,

I have to say it will become an urgent issue if this workaround has any defects.

I have already tried a few of our test modules, and they work.
The next step will handle our mass product.
It would be very helpful if the TI team could confirm this workaround, since any failure could cause the MCU to become permanently locked.

While I know it works, I'm uncertain about potential side effects or risks due to the lack of information in the technical reference regarding this operation.

If it's okay, could your team provide an example of "C Code Example to Change the PW"?
(like section "1.2.3.3.1 C Code Example to Unsecure" in the technical reference)

Hi Steven,

To provide confirmation that this is a reliable solution I would need to simulate this behavior as this is a very old device and the knowledge of the CSM on our team is limited. I'm assuming a simple test using CCS on my side would produce the same results as what you've observed without providing clear confirmation.

Simulation is reserved for very high priority / urgent customer issues. If you're able to validate this behavior on your end sufficiently without simulation that would be preferred, otherwise this issue will need to be escalated over email to confirm the CSM behavior.

Thank you,

Luke

Hello Luke,  

Following our discussion, this issue has become urgent and a high priority.  

Please confirm if this workaround is reliable, including an analysis of potential side effects and risks.

Best regards.

Understood, can you aid with the testing process by providing two .out files:

1) working code with debugger disconnected

2) non-working code with debugger disconnected

Thank you,

Luke

Hello Luke,

I can't provide the file since it includes customer information.

Please implement the workaround on your side and confirm whether it is reliable, including an analysis of potential side effects and risks.

(The MCU is secured with a password first.)
Step 1. Read the password and store it in RAM
Step 2. Unsecure the MCU with the password obtained from Step 1
Step 3. Erase Sector A
Step 4. Write Sector A with the new program code
Step 5. Write the password (get from Step 1)
Step 6. Resecure the MCU

Best regards.

Hi Steven,

This will take me some time to both create the test cases and simulate them myself. I will keep you updated on my progress.

Thank you,

Luke

Hi Steven,

I am still working on getting access to our simulation tools. Will let you know once I obtain access.

Thank you,

Luke

Hi Steven,

I won't be able to address this issue for another few weeks, I see you have not replied on the thread in over a month but let me know if this is still an urgent issue.

Thank you,

Luke

Hello Luke,

Yes, it's still an urgent issue.

Hi Steven,

I still have higher priority items I need to address before spending time on this. If you're able to create .out files to show the working and non-working cases, I may be able to find someone from our design team to simulate and diagnose the issue.

Thank you,

Luke

Hello Luke,

As mentioned earlier, I am unable to provide the .out file since it contains customer information.

I understand, I am suggesting providing a similar .out that does not contain sensitive customer information but still shows the same error.

Hello Luke,

It's difficult for us to separate this information because our development relies on the software package supplied by our customer.

We hope that the TI team can implement the workaround based on a simple environment to focus on this issue.
(Ex. Using Piccolo TMS320F28035 Isolated controlCARD <-- We don't have this kind of resource)

Hi Steven,

I will see if I can generate .out files for this issue sometime this week.

Thank you,

Luke

Hello Luke,

Thank you for your assistance. I will wait patiently for the results.

Hi Steven,

Unfortunately I am out of office starting Friday until August 19th and I did not have time to create a .out this week. Apologies for the additional delay.

Thank you,

Luke