TMS320x2806x Piccolo Code Security Module (CSM) programming using CCS V4.1

Yeshwanth,

I am not clear from your post if you successfully programmed the device with the passwords or if you got an error when doing it.  Assuming the passwords are programmed, you are probably getting bitten by the ECSL (enhanced code security logic).  The ECSL disconnects JTAG if any access is made to CSM secure memory.  You can read about it in the device datasheet SPRS698D, section 2.5.11.

I assume your device is configured in jump-to-flash bootmode, and as soon as you release the device from reset it starts executing your code in flash.  This triggers the ECSL and disconnects the JTAG.  You then cannot get back in using CCS.  The thing to do is rig your bootmode into "Wait" boot temporarily.  See Table 2-6 in the datasheet for pin settings.  This will cause the F2806x to stay in an endless loop in the boot ROM.  The ROM is NOT CSM secure.  You can then connect using CCS, and unlock the CSM.

All this assumes that your passwords were successfully programmed into the flash.  If they weren't and you had some sort of problem during flashing, the passwords may be corrupt/unknown.  If that is the case, you cannot get back in to the device and will need to replace them on your boards.

Regards,

David

Hi David,

Thank you for your support. It worked!!! :)

After doing specified pin setting to put boot mode in 'wait', the device got connected. I checked the PWL and found my pwd written in those locations.After that I diconnected and connected and programmed pwd several times, all is fine.

A small doubt in working of CSM:

We have a small bootloader function of our own to perform firmware update. This function receives hex file from PC via USB and stores the data in application sector. For this task it uses library function in bootROM (Unsecured area). Hence I have to unsecure the device before performing this task. To Unsecure I perform Password Match Flow and unsecure my device.

My question is when I have unsecured the device internally during usb firmware update; is it possible for a hacker to connect JTag or via any device or pins from controller and read or modify the flash.

Would you kindly clarify this doubt.

Thank you,

Yeshwanth S

Hi David,

I fount this piece of code in bl_Config.h. under what conditions and for what purpose should I comment or uncomment this part of code:

"//*****************************************************************************
//
// Enables CSM Lock/Unlock mechanism based on a seed key exchange.
//
// Due to export restrictions this feature has been removed from the public
// release of the F2806x USB Bootloader.  If you are interested in this please
// contact TI via email or the e2e forums.
//
// Depends on: None
// Exclusive of: None
// Requires: None
//
//*****************************************************************************
//#define ENABLE_CSM_CONTROL
//
//#ifdef ENABLE_CSM_CONTROL
//#include "aes.h"
//
//#if KEY_FORM & KEY_PRESET
//#include "enc_key.h"
//#endif
//
//#define PWL0    0xFFFF
//#define PWL1    0xFFFF
//#define PWL2    0xFFFF
//#define PWL3    0xFFFF
//#define PWL4    0xFFFF
//#define PWL5    0xFFFF
//#define PWL6    0xFFFF
//#define PWL7    0xFFFF
//
//#endif
"

Thank you.

Yeshwanth,

You are quite correct that if you want to maintain code security during flash reprogramming, you cannot use the ROM flash APIs.  Instead, you need to incorporate the flash APIs into your own code with load to flash and run from secure RAM (because you cannot execute the flash APIs from flash).  The APIs are available as a C-callable object code in ControlSuite for F2806x devices.

What you should do is incorporate the APIs into your 'secondary' bootloader (as opposed to the TI ROM bootloader), and the secondary bootloader should reside in flash sector A.  Sector A should never be erased or upgraded in the field.  It contains your secondary bootloader and also the CSM passwords.  That way, if something goes wrong during flash upgrading (e.g., power loss), you can re-boot the device and try again.  Also, since the APIs will execute from CSM secure RAM, there is no need to unlock the CSM.  Also, the passwords will never be erased.  Therefore, CSM security is maintained at all times.

Note that you may want to use some sort of password scheme to activate the flash reprogramming.  The issue here is that you are downloading new code that will get programmed into the flash.  Knowing this, a hacker could activate the reprogramming function and download rogue code (that will be put into secure flash) that will read the passwords from the flash and unlock the CSM.  You don't want this.  So, you want to make sure that only authorized personel can activate the reprogramming function.  Some people use a simple CRC check on a header for the new code (the CRC must always come out to some particular value or the reprogramming will not start).  I've even seen some users encrypt the new flash data and unencrypt inside the C28x as part of the reprogramming function.  This approach makes it really impossible for a hacker to substitute rogue code.  It also allows you to freely distribute your new code since nobody can decrypt it anyway.  Of course, the decryption in you secondary bootloader will consume more code size.

The downside of having the APIs incorporated into your bootloader is increased code size.  But that is the price you must pay.  There is no other way to do this.

-----------

On the bl_Config.h question, I think this was intended for use in the USB ROM bootloader so the user could unlock the CSM via a key exchange.  I don't think you're supposed to touch this.  I don't know much about the USB bootloader.  If you are interested in that, you should start a new thread and someone on the C2000 team that knows that bootloader will pick it up for you.

Regards,

David

Hi David,

As mentioned earlier, when I am switching to USB firmware update mode, I am unsecuring the device. During this time If an emulator is connected via JTAG, isn't it mandatory that the emulator has to reset the controller to connect or is it possible to connect to controller without resetting it.

The reason I am rising this question is; if its mandatory that emulator resets the controller efor connecting the the controller automatically locks itself right, so the JTAG device can't connect without correct PWD. Kindly, help me to understand this concept.

..........................................................................................................................................................

About activating the flash reprogramming, I am looking at possibility of autherization of the user in the PC tool. I will also see the other two options recomended by you. they look more secure way of doing things.

Thank you for your kind suport.

An emulator does NOT need to reset the device to connect.  If you unsecure the device, a hacker can get in at that time.  As I indicated in my previous post, you want to do the flash reprogramming with the CSM secured.  If you unlock the CSM, your code is exposed.

Regards,

David

Hi David,

Many thanks, I will implement the way you had recommended in your previous post to completely secure my device.

Thanks once again,

Best Regards,

Yeshwanth S