[FAQ] C2000WARE: Why is my DCSM configuration causing issues in my application?

Best practices when using DCSM:

1. When using SysConfig to generate and program DCSM settings as part of your .out or .hex file, finalize all DCSM settings before programming ANY DCSM settings: Understand that DCSM settings are programmed in OTP (one-time programmable memory). This means that any bit in OTP that has been programmed to a 0 cannot be erased or reprogrammed to a 1. Additionally, all DCSM OTP locations (with the exception of the linkpointer and JLM enable) have corresponding ECC bits that also exist in OTP. This means that programming any OTP location will result in the corresponding ECC bits to get programmed as well. The combination of OTP protection and ECC protection results in a scenario where any 64-bit block in OTP can only be reliably programmed a single time. When using SysConfig to generate DCSM settings, the generated .cmd and .asm files will specify values for ALL OTP locations, resulting in ALL OTP locations getting programmed even if default values were selected for most DCSM settings. Programming a .out file that used SysConfig for DCSM settings can easily result in a scenario where all unused OTP locations are permanently programmed with undesirable / default values. As a workaround, it is advised to use SysConfig only to view the correct OTP values based on desired settings, but then create custom .asm and .cmd files (using the autogenerated .asm and .cmd files as a reference) in your project where only the settings you wish to change are specified in the .asm and .cmd files. Note that you must specify your OTP values in 64-bit blocks or else the generated .out file will attempt to program all Fs in any portion of a 64-bit block that is not specified. For example, you must specify all 64 bits from address 0x78000 to 0x78003 (all 3 linkpointers + JLM enable).

Issue #1: Flash programming is interrupted immediately after programming custom CSMPSWD values for the first time:

This issue occurs under the following conditions:

• F28003x or newer device is in use(refer to device list in the original post, devices are listed from oldest to newest)
• CSM password values being programmed are different from the default passwords
• This is the first time programming a .out or .hex file that contains custom CSM passwords
• The "verify" option is enabled in CCS On-Chip flash tool or Uniflash

To understand the cause of this issue we must first understand the following behaviors of DCSM:

• When a memory location is "secured" by a zone, it cannot be read or written to by any unauthorized source (JTAG or code residing in unsecured memory, or memory secured by another zone)
• When a DCSM zone is locked, the USER OTP corresponding with the zone becomes secured memory (USER OTP for Zone 1 includes addresses 0x78000 to 0x781FF)
• A DCSM zone is locked anytime the values in the CSMKEY registers do not match the password values that have been dummy loaded via a dummy read of the CSMPSWD values in USER OTP
• On an unprogrammed device, the Boot-ROM automatically dummy reads the CSMPSWD locations in USER OTP and programs the default CSMPSWD values in the CSMKEY registers, resulting in an unlocked DCSM zone upon completion of the Boot-ROM code :)
• Enabling the "verify" option in the CCS On-Chip flash tool or Uniflash will result in the JTAG performing a read of each memory location immediately after programming each location during flash / OTP programming.

Once the above is understood, think about what will happen when we program a unprogrammed device with a .out or .hex file that contains custom CSMPSWD values over JTAG.

1. Before programming, our DCSM zone is unlocked.
2. The JTAG will program and read back the specified OTP values from 0x78000 to 0x78020.
3. The CSMPSWD locations(between 0x78020 and 0x78028) are then programmed
4. a dummy read will be performed on the CSMPSWD locations which will dummy load the password values and create a mismatch between the dummy register and CSMKEY.
5. This will immediately lock the DCSM zone, which will cause USER OTP to become secured memory,
6. This prevents the JTAG from programming any further OTP locations, starting at address 0x78028.

Workarounds / solutions: before programming custom CSMPSWDs for the first time, disable the verify option to prevent this issue. If this issue has already occurred this is OK. You simply need to unlock the DCSM in the On-Chip flash tool or Uniflash tool using your custom CSMPSWDs and attempt to program again. On the second programming attempt, this issue will not occur, since the unlocking procedure will program the custom CSMPSWD values to the CSMKEY registers, preventing the key/password mismatch and keeping the DCSM unlocked throughout programming.

The error at 0x78028 is a tell-tale sign of this specific issue. Errors at other addresses indicate something else has gone wrong.