[FAQ] Common CSM and Flash Questions

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:

• F28M35x
• F28M36x
• 2806x
• 2802x
• 2803x
• 2833x
• 2823x
• 280x
• 281x

Nomenclature

• 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.

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.

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

• 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.

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).

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

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.

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

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

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.

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.

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.

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.

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:

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).

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: http://emulators.spectrumdigital.com/utilities/sdflash/c2000/SDFlash_Serial_RefGuide_v3_3.pdf

Frequently Asked Questions ECSL

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.