How to use C2000 CSM

fish001

How to use C2000 CSM [Copy link]

This post was last edited by fish001 on 2020-7-5 16:26

In the TI C2000 series DSP, the CSM module is used to encrypt the chip to prevent unauthorized code reversal and other behaviors. TI describes this module in its documentation as follows:

The code security module (CSM) is a security feature incorporated in 28x devices. It prevents access/visibility to on-chip memory to unauthorized persons—that is, it prevents duplication/reverse engineering of proprietary code.
The word secure means access to on-chip memory is protected. The word unsecure means access to onchip secure memory is not protected — that is, the contents of the memory could be read by any means (through a debugging tool such as Code Composer Studio, for example).

For details about which parts of the DSP are protected by the CSM module and the details of this module, please refer to TI's relevant documents. Here we only discuss how to encrypt and decrypt the DSP chip from the perspective of usage. This article is based on CCS 6.0.

Password setting

The simplest method is to directly use DSP28***_CSMPasswords.asmthe file provided in controlSUITE, add this file to the project, and modify the password. The content of this file is as follows:

.sect "csmpasswds"

.int	0xFFFF		;PWL0 (LSW of 128-bit password)
.int	0xFFFF		;PWL1
.int	0xFFFF		;PWL2
.int	0xFFFF		;PWL3
.int	0xFFFF		;PWL4
.int	0xFFFF		;PWL5
.int	0xFFFF		;PWL6
.int	0xFFFF		;PWL7 (MSW of 128-bit password)

.sect "csm_rsvd"
.loop (3F7FF5h - 3F7F80h + 1)
      .int 0x0000
.endloop

The corresponding address allocation in the CMD file:

MEMORY
{
PAGE 0:    /* Program Memory */
   CSM_RSVD    : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
   CSM_PWL_P0  : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */
}
SECTIONS
{
   csmpasswds          : > CSM_PWL_P0  PAGE = 0
   csm_rsvd            : > CSM_RSVD    PAGE = 0
}

There are some key points to note when setting a password:

Setting all to 128-bit 1means no encryption, the so-called "insecure".
Setting all 128-bit to 128-bit 0means permanent encryption. The chip cannot be decrypted, which means it cannot be programmed or read. Generally, do not set this.
If the lower 64 bits of the 128-bit are set (i.e. not full 1), the so-called ECSL (Emulation Code Security Logic) function will be triggered. At this time, if you need to use the emulator to download the program, some special settings are required, which will be discussed in detail below.

Download the program using the emulator after encryption

If the chip is not encrypted, you can use the emulator to download the program through JATG. However, if the chip is encrypted with a password, you need to enter the password correctly in the emulator settings to download the program and debug. Specifically, there are two situations: no lower 64-bit password is set and the lower 64-bit password is set.

No lower 64-bit password is set

At this time, the ECSL function is not triggered. As long as the password is correctly filled in the emulator settings, the program can be downloaded normally. Taking CCS v6.0 and XDS100V3 emulators as examples, the setting interface is shown in the figure: The

CSM password set in the figure is 0xAAAABBBBCCCCDDDDFFFFFFFFFFFFFFFF.
After setting, you can debug normally.

A low 64-bit password is set

The situation is more complicated at this time. When the lower 64-bit password is set, the ECSL function in the DSP will be triggered. Regarding this function, the description in the TI document is as follows:

In addition to the CSM, the emulation code security logic (ECSL) has been implemented to prevent unauthorized users from stepping through secure code. Any code or data access to flash, user OTP, L0 memory while the emulator is connected will trip the ECSL and break the emulation connection.

When initially debugging a device with the password locations in flash programmed (that is, secured), the emulator takes some time to take control of the CPU. During this time, the CPU will start running and may execute an instruction that performs an access to a protected ECSL area. If this happens, the ECSL will trip and cause the emulator connection to be cut.

In short, when the ECSL function is enabled, the JTAG connection between the emulator and the device will be forcibly cut off, causing the connection to fail. At this time, even if the password is set correctly according to the previous steps, the program cannot be downloaded. After clicking the Debug button, the following error message will appear:

C28xx: Error connecting to the target: (Error -1015 @ 0x0) Device is not responding to the request. Device may be locked, or the emulator connection may be unreliable. Unlock the device if possible (e.g. use wait in reset mode, and power-cycle the board). If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.450.0)

This error message is different from the message when the password is incorrect. The message when the password is incorrect is as follows:

C28xx: Flash Programmer: Device is locked or not connected. Operation cancelled.
C28xx: Error Writing Flash @ Address 0x003F74C6 of Length 0x00000016 (page 0)
C28xx: GEL: File: D:\Forklift\MS8000V10\Project\Release\MS8000V10.out: Load failed.

There will be a dialog box prompting:

TI's documentation also provides a solution to this problem:

The first is to use the Wait-In-Reset emulation mode, which will hold the device in reset until the emulator takes control. The emulator must support this mode for this option.

The second option is to use the “Branch to check boot mode” boot option. This will sit in a loop and continuously poll the boot mode select pins. You can select this boot mode and then exit this mode once the emulator is connected by re-mapping the PC to another address or by changing the boot mode selection pin to the desired boot mode.

In short, the first method is to keep the device in reset state until the emulator takes over the device, which requires the support of the emulator and the device; the second method is to configure the BOOT pin to make the DSP enter a so-called "Branch to check boot mode" and then connect the emulator. The
XDS100v3 emulator I use does not support the first method. In the emulator settings, the "Halt the target on a connect" item is not selectable, as shown in the figure:

At this time, only the second method can be used. However, the document does not clearly indicate what the "Branch to check boot mode" in the second method specifically refers to. However, the correct operation method is given on TI's Wiki Page:

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:

Disconnect your emulator.
Set your boot pins for “WAIT” boot mode. Note: on 2833x/2823x this is documented as the “loop to check” boot mode.
Reset your device.
Reconnect your emulator.
At this point you should be able to proceed and unlock your device.

In short, for 2803x series MCU, you need to reset the DSP to enter the Wait mode before connecting the emulator to successfully download the program . As for how to enter the Wait mode, you can find it in the device reference manual. Taking 28031 as an example, pull GPIO34 low when powering on (GPIO34 has an internal pull-up by default):

Actual tests show that with this setting, the program can be downloaded and debugged normally through the emulator.