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.

[FAQ] Common CSM and Flash Questions

Sometimes a device may unexpectedly be locked.  This FAQ addresses some common reasons.

  • Introduction to the Code Security Module (CSM)

    The CSM is documented in the system control and interrupts guide for the specific device. This page refers to the Code Security Module available on the following C2000 device families:


    • CSM: Code Security Module
    • ECSL: Emulation Code Security Logic
    • Password Locations: The CSM password is a 128 bit value stored in 8 words of flash. The password locations refer to these 8 words.

    Reasons CSM Appears Secure

    There are 5 different situations in which the CSM would either be secured or appear to be secure:

    1. Password Match Flow has not been completed
    2. The CSM has been knowingly programmed with a password
    3. The CSM has been unknowingly programmed with a password
    4. The CSM has been permanently secured by programming all zeroes into the password locations
    5. The flash is not powered as a result of the VDD3VFL power signal not being present

    The solutions to above conditions are as follows:

    1. Run the password match flow by the method described in the CSM section of the System Control and Interrupts Reference Guide for the specific TMS320F28xxx device being used. This can easily be utilized from the device GEL file within CCS by selecting GEL -> Code Security Module -> Unlock_CSM().
    2. Unlock the CSM with the password that was programmed to it previously. The process to unlock the CSM with the CCS On Chip Flash Programmer is discussed in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.
    3. The previous .out file that was programmed to the flash could contain data that was written to the password locations. In this instance the Hex Conversion Utility supplied with CCS can be used to convert the .out file to a hex format and determine what data was written to the password locations. These values can then be used to unlock the CSM. If this .out file does not show data written to the password locations or the .out file is not available, the flash cannot be unlocked and the chip should be replaced.
    4. The CSM cannot be unlocked as all zeroes permanently secures the CSM. The CSM could have been permanently locked on purpose or could be the result of power failure or by stopping the erase procedure during previous programming cycle. This is discussed further in SPRAAL3.
    5. The VDD3VFL signal is either not present or is not supplying a clean power rail to the flash resulting in the flash not being powered. This will need to be corrected on the target board. This is discussed further in SPRAAL3. If the device is in a socket, make sure it is properly seated and making good connection.

    In any of these cases, if the CSM is secure and the password is unknown, it cannot be unlocked to be reprogrammed.

    Halting Erase Operation

    If the erase operation is interrupted and not allowed to complete, the flash may become depleted. When this happens, the device may then begin to fail to erase. The erase algorithm should not be stopped, as this can also affect the CSM passwords. If the passwords are in an unknown state, the device cannot be recovered. This can also leave all zeroes in the CSM resulting in a permanent lock. This is discussed further in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.

    Frequently Asked Questions CSM

    Q: What are the scenarios that CSM gets locked automatically? Is it deterministic or not?

    • If a password is programmed into the flash, the CSM is locked on reset and stays this way until the password match flow is executed (refer to the System Control and Interrupts guide for your particular device).
    • If an application has unlocked the device, it can force a re-lock by writing a 1 to the FORCESEC bit in the CSMSCR register.

    Q: Why is all 0xFFFF's unsecure?

    When the device leaves the factory the flash is in an erased state. In this state all locations, including the password, is all ones (i.e. 0xFFFF's).


    Q: How many passwords are there?

    There is one 128-bit password. It occupies 8 contiguous words in flash.


    Q: How do you unlock the the CSM after all zeros have been written to the password locations?

    When all zeroes are written to the password locations, this is a permanent lock and there is not a method to erase this password. This is documented in the CSM section of the System Control and Interrupts Reference Guide for the specific device being used. This section provides the following statement:

    Do not use 128 bits of all zeros as the password. This automatically secures the device, regardless of the contents of the KEY register. The device is not debuggable nor re-programmable.


    Q: Is there any way to erase the password?

    If you know the password then you can unlock the flash and erase the password by erasing sector A.


    Q: Is there any way to erase the password without erasing all of sector A?

    No. The smallest amount of memory that can be erased is a sector.


    Q: Code that is running in unsecure memory cannot read/write to memory that is secure or from Flash - why?

    If the CSM is locked, then code running outside of the secure area will not be able to read or write to any secured location. The CSM must either be unlocked or the code must be relocated to one of the secure areas.


    Q: Will the CSM block the boot loader running in the boot ROM?

    The boot ROM itself is unsecure and the boot ROM performs a dummy read of the CSM password locations.

    • If the device password is not programmed, then this will unlock the CSM and the boot loader will be able to write to secure memory.
    • If the device password is programmed, then the CSM will remain locked. In this case the boot loader will not be able to write to secure memory. One option is to provide your own loader in your application within secure memory (e.x. Flash). Using this loader you will be able to load to secure memory.

    Q: Code is running outside of the CSM protected area, and the CSM is locked. Can it branch to code within the CSM protected memory?

    Yes, you can branch into the secured memory and begin execution without any additional setup.

    Note: this is different then trying to read values out of the flash through data or program space - this will be blocked. For example, code running in M0 SRAM (unsecure) can branch to code within the Flash even if the CSM is locked. Code running out of M0 SRAM will not be able to read any value out of Flash if the CSM is locked.


    Q: How can I tell which memories are protected by the CSM?

    Refer to the Data Manual for the particular device. Memories that are protected by the CSM will be indicated in the memory map section. For example if L0 shows "Secure Zone" then it is protected by the CSM.


    Q: The CSM locks every time I reset the device via Code Composer. Is this the intended behavior? Is there a work around?

    Yes this is the intended behavior. It is easy to get around this during development. You can do one of two things.

    1. open a memory window in CCS to the CSM passwords. This will force CCS to read the passwords every time you halt or reset. If the password locations are erased (all 0xFFFF's) then this will unlock the CSM.
    2. In the gel file place the Unlock_CSM(); gel call in the OnReset() function to automatically unlock the CSM each time the processor is reset. That is:
    OnReset(int nErrorCode)

    Q: To unlock the CSM, does the dummy read come first or the load of the KEY registers first?

    Either order will work. The ref guide says to do dummy reads of the PWL first, then write the passwords to the KEY locations. Some other examples may do it in the opposite order (i.e. loads the KEY registers and then does a dummy read of the PWL).


    Q: Is it possible to program a device over the serial port with SDFlash if it is password protected?

    Yes. The SDFlash algorithm will need to be built such that it knows the password of the device and can unlock it. This is easy to do and is described in the readme file for the serial algorithm:

    Frequently Asked Questions ECSL

    Q: Why does Code Composer Studio give me an emulator error when I try to connect to my locked device?

    On devices with ECSL protection which do not support hardware wait-in-reset mode (such as the Piccolo devices), if the device is locked:

    When the device is powered up, the CPU will start running and may execute an instruction that performs an access to an ECSL protected area. If this happens, the ECSL will trip and cause the emulator connection to be cut. To resolve this:

    1. Disconnect your emulator.
    2. Set your boot pins for "WAIT" boot mode. Note: on 2833x/2823x this is documented as the "loop to check" boot mode.
    3. Reset your device.
    4. Reconnect your emulator.

    At this point you should be able to proceed and unlock your device.