This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

firmware code protection on a C5515 DSP using external SPI EEPROM ?

Other Parts Discussed in Thread: TMS320C5515

Hi,

Not entirely sure if this is possible however I'm willing to hear all suggestions. Basically we're looking at a way to protect our firmware code from reading and/or modification once it's been loaded into the external SPI EEPROM. Our custom designed C5515 based DSP board uses the internal boot-loader to load the firmware code from the external EEPROM via SPI. Is there a way to prevent reading of the code, say by encrypting the code and decrypting it with the boot-loader, then preventing JTAG access to the DSP by blowing a DSP fuse or something like that ? Otherwise, the internal ROM can it be used to program the DSP with the firmware (once we have a stable version etc.) ? Any other suggestion perhaps more practical ?

Thanks in advance for any info.

Regards, Mike

  • Hi,

    It appears SPRAB92 has some details doing exactly that which we need, unless otherwise, it seems I found what I was after in this document. I presume its also valid for the C5515 etc....

    Cheers, M

  • Yes,5505/04/15/14 supports encypted boot-image and also provides an option to disable JTAG. Once approved, we provide a tool to create an encryped boot-image.

    Please contact your local sales and let them contact C5000 marketing team if you need detail info and the tool.

    Best Regards,

    Peter Chung

     

  • Hi Peter,

     

    I'm interested in that JTAG disable option. Can you please let me know any details?

     

    Thanks,

    Christos

     

  • Christos,

    I will let our marketing team answer your question.

    Regards,

    Peter Chung

     

  • Hello Mike and Christos,

    As Peter has mentioned in his reply we do support a secure boot process where the decryption of the encrypted boot image is handled by the bootloader itself. You can go a step further and choose the option (while encrypting your boot image) to have the DSP re-author the encryption during the first power-up. This means that the DSP will decrypt the image, re-encrypt it using the Unique Device ID of the device as the key and overwrite the original encrypted image. This happens only once after the first power up and basically binds the encrypted boot image to run only on that particular silicon device for added security.

    We provide JTAG disabled silicon on request for your production order. This condition can be reversed once in our fab for debug purposes and then JTAG can be disabled again permanently for the last time. The JTAG can also be disabled by grounding the TRST pin on the board, but this is not really secure.

    If you so choose, we can have custom ROM devices with your code on it but this would include some sort of NRE + minimum order conditions.

    Please contact your local TI or disty sales person for next steps if you decide to take advantage of any of these options.

    Regards,

    Sunil Kamath

     

     

  • Hi Sunil,

    It is OK if the DSP re-authors the encryption during the first power-up. Presumably the SPI FLASH could all be factory preprogrammed, then loaded on the production boards etc. On first power-up the image-DSP binding occurs as you suggest. Yes this would interest us as long as we can always re-flash the FLASH memory with firmware updates via SPI or JTAG etc. I would assume this is OK, but can you please confirm anyway that your proposed image-DSP binding of the encrypted firmware will eventually allow for further firmware updates when required ?

    Regards,

    M

  • Hi Mike,

    Yes, firmware update is possible. You will of course not be able to use the JTAG if you use JTAG disabled silicon. Otherwise, you should be able to get an updated boot image - encrypted or un-encrypted into the device through UART, SD card, USB, SPI or I2C and have a programmer code (which would be part of your application) over write the re-authored image. And if you have chosen the re-authoring  option, the DSP will encrypt and bind the image to the device again during the next power up.

    Regards,

    Sunil Kamath

  • Hello Mike, Sunil,

    I also want to do a code protection on my C5515 DSP using an SPI Flash.

    I am using the "C55BootImageV2.exe". If i'm using the option "Not Bound to Device" everything works fine. If I use "Re_Author and Bound to Device" it doesn't work (device doesn't boot after power up).

    Do I have to use other options for the Secure/Encrypt Parameters? (Key: 0x10000000, 0x00000100; Seed_Offset: 0x00000000; Seed: 0x2F71C554, 0xEEDF6500)

    Are there any requirements how to choose these parameters?

    If you have an idea why it doesn't work please let me know.

    Regards,

    Martin

  • Hello again,

    according to the bootloader datasheet Re-Authoring is not possible with 24-bit SPI serial flash!

    Regards,

    Martin

  • Hi Martin,

    Yes I can confirm I also had a problem with using this re-authoring option of the BootImage software.  However I must admit I never found a reason why and certainly nothing so specific about the 24-bit flash SPI not being compatible with this particular option of the bootimager. On what page of this datasheet is it actually mentioned ? Just curious really ... perhaps I was looking at another version of the datasheet or maybe just the wrong one (that would be silly of me ;-)... ?!?

    Regards, M

  • Hi!

    I just downloaded the Datasheet "Using the TMS320C5515/14/05/04 Bootloader" (SPRABD7A–June 2010–Revised January 2012) from the TI-homepage. On page 2 it is mentioned that reauthoring is supported for NOR, NAND, 16-bit SPI EEPROM, I2C EEPROM, and MMC/SD. With the 24-bit SPI serial flash both secure and unsecure images are possible, but no reauthoring.

    Regards,

    Martin