TMS320F28027: Firmware automatically resets when CSM is locked

I don’t believe the CSM is the one initiating a reset. CSM only blocks access to secure resources when the JTAG is connected. From the TRM: 

"The device is secure when CPU access to the on-chip secure memory locations is restricted. When secure, two levels of protection are possible, depending on where the program counter is currently pointing. If code is currently running from inside secure memory, only an access through JTAG is blocked (that is, through the debug probe). This allows secure code to access secure data. Conversely, if code is running from nonsecure memory, all accesses to secure memories are blocked. User code can dynamically jump in and out of secure memory, thereby allowing secure function calls from nonsecure memory. Similarly, interrupt service routines can be placed in secure memory, even if the main program loop is run from nonsecure memory"

Please try the following:

• Disable the watchdog in your application, if it is currently enabled.
• If WD is already disabled in your application, try this: Program a very simple code (such as toggling a GPIO pin that you can monitor externally) into flash. Run this example with and without security.

Disabling the watchdog changes the behavior from resetting to simply being unresponsive.  So to be technically correct, the system is resetting because of watchdog timeouts, but only when CSM password has been set.  If this is due to an illegal memory access, does that necessarily mean code running in unsecured memory is accessing secured memory?  Is this something that I should be able to locate in the map file?

Clearly, it is the WD resetting your device. You can confirm this by measuring the width of the reset pulse; a reset initiated by the WD would be 512 OSCCLK cycles wide. There is some issue in running the routine that services the WD. In which memory is this routine running from right now?

All code that touches the watchdog runs from flash.

If I understand it correctly, the only place code can run from that is unsecure is M0/M1 SARAM.  The only thing allocated to this memory is the stack.

So there is no problem running the application from flash per se. Without the JTAG connector connected, no matter how many times you cycle power, your application correctly boots up, runs, services WD etc, provided device is not secured with passwords. 

If the device is secured with passwords, application runs fine as long as unsecure routine is executed as part of the application. 

You see the problem only when the device is secured with passwords and the unsecure routine is not executed. 

Have you tried increasing the stack size?

I added 0x100 to the stack, and saw no change.  If this is a result of illegal access, wouldn't that be reflected by code running out of M0/M1 SARAM?  I have nothing running out of this section.

What you say is true. To summarize: 

• On a secure device, CPU can fetch code from secure memory for execution. No explicit unsecuring by the application code is needed. This is how applications normally run.
• Code running in secure memory will be able to read any location in another secure memory.
• However, code running in unsecure memory can access a location in secure memory only after the Password Match Flow (PMF) i.e. after the passwords are written in the KEY registers and the device is unsecured. 

Since you are not executing code off M0/M1, please try my suggestion below: 

Program a very simple code (such as toggling a GPIO pin that you can monitor externally) into flash. Run this example on a secure device with and without executing the unsecure code in your application.

I have tested that I am able to toggle an IO repeatedly without resetting, in both the locked and unlocked scenarios.

OK, it appears there is something going on in your application that is preventing the servicing of WD. It is hard for me to discern what could be happening. Problems of this nature warrant hands-on debug and remote debug may not be effective. One suggestion: you could toggle a GPIO pin different number of times in different parts of the code to "trace" how far your application executes. Beyond this, I am unable to think of anything right now.

I've narrowed it down at least the first place this is problematic.  When I initialize the CTRL subsystem, one of the functions called is CTRL_setEstParams.  This function is a ROM function.  A variable that lives in L0 SARAM gets passed into this function.  Thus, ROM code (unsecured) is accessing secured RAM.  I don't understand why this causes the WD to go unserviced, but unlocking just before, and relocking just after calling this function seems to allow the code to keep running.

There are alot more codepaths to check, when the system is actually driving the motor.  Can you confirm that ROM functions accessing secured RAM is a violation of the secured memory?

Please clarify “ROM”. Are you referring to the Boot-ROM? I don’t think so as it doesn’t contain a function called “CTRL_setEstParams”, AFAIK. Or are you referring to the User OTP, which is secure?

After further examination, I think its actually CTRL_initCtrl() that is the offending function call.  If I call CsmLock just before this function, I reset after a WD timeout.  If I call CsmLock just after this function, my application continues to run, at least in the idle state.  Looking in the map file, I found this line:

abs   003fd88b  _CTRL_initCtrl

This address is not represented in either table in the TRM that describe which memories are secure, and which are not.

That address is part of IQMATH: IQMATH                003fec86   0000082a  0000082a  00000000  RWIX

Please refer to the boot-ROM map file at C:\ti\c2000\C2000Ware_3_04_00_00\libraries\boot_rom\f2802x\v2_0\rom_sources\Release. That address is part of boot-ROM, which is not secure.

Refer to Fig 9-1 in SPRS523P for device memory map.

0x3FD88B is not in the IQMATH section.  According to the memory map, 0x3FD000 - 0x3FDFFF is a reserved section.  Is this still unsecure?

What is the difference between just-in-time unlocking, and unlocking at the top of main, and never relocking?  Is one less secure than the other?

Hi Todd,

Todd Muir2 said:

A variable that lives in L0 SARAM gets passed into this function.  Thus, ROM code (unsecured) is accessing secured RAM.  I don't understand why this causes the WD to go unserviced, but unlocking just before, and relocking just after calling this function seems to allow the code to keep running.

As you know ROM is unsecure and it can not access content from secure RAM hence ROM function will not be able to access the variable hence execution of code may not happen as expected and WD service code may never get executed. After you unlock the CSM it works fine since there no security restriction anymore. You need to examine your code and do proper partition of code so that none of the non-secure function should access any content from secure memory. That should resolve the issue you are facing.

Regards,

Vivek Singh

If I unlock the csm at the top of main, and never lock it, does that leave the system open to being read from JTAG, or does it remain secure?