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.

TMS320F280049C: Securing a custom flash bootloader so that it can't be erased

Part Number: TMS320F280049C


I would like to secure 2 sectors of flash for a custom bootloader that is protected from being erased. I want to be able to boot up into this section of flash and be able to execute from it, while also transferring a re-flash algorithm from this section to RAM for execution if a re-flash is necessary.  Is it possible to boot up into a secured section of flash memory?

  • Philip,

    I would take a look at this SW resource(and the app notes that are linked) https://software-dl.ti.com/C2000/docs/software_guide/c2000ware/lfu.html  this describes how to implement a live FW update scheme using 2 flash blocks as you have mentioned.

    In terms of securing the flash so that it cannot be erased, I would refer to the F28004x TRM, page 144 details how the DCSM, when activated, will block the flash API from erasing/re-programming the different flash sectors if the DCSM is locked.  For re-programming you can either unlock the device, or the flash API can be ran from a secure memory that belongs to the same zone as the flash.  The DCSM chapter will be useful in general for what you want to do.

    Best,
    Matthew

  • Thank you. As I read through the DCSM chapter of the TRM, I still have one question. What is the benefit of having so many Zone Select Blocks?

  • Philip,

    Since the information for the security(Passwords, GRABRAM, EXEONLY, etc) is stored in OTP it can only be written to 1 time.  If you want to change these parameters then we need another set of OTP locations to write the new values.  The Zone Select Block that is used is configured in the Link Pointer(image below, click on it to zoom in) from the TRM on page 141

    Probably more for debug and less for something in production, this allows the user 30 different configs until the device can no longer be changed.  

    On older C2000 devices(Gen 1 and Gen2) this info was stored in regular flash memory, which could be erased/reprogrammed as needed so there was not a need for multiple zone select blocks.  We moved the passwords and other selects to OTP on Gen3 to resolve an issue where if the main array program/erase operation was interrupted it could not corrupt the passwords, which could result in a permanently locked device.

    When we did this we needed a way to allow more than one chance to configure these bits, hence the Zone Select Blocks.  We felt 30 should be enough "opportunities" for changes without being too restrictive on the customer.  As I said, 30 is probably way more than most applications need for their lifetime for these features.

    Best,
    Matthew