TMS320F28388D: GRABSECT/RAM CSM Settings Caused Unresponsive Board

Part Number: TMS320F28388D
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

I'm using an assembly file to setup CSM settings for 28388D. After changing the GRABSECT/GRAMRAM values, my application stopped working once the file was programmed. Note, I have used this file to lock the JTAG and develop CSM logic, but I am having problems with allocating memory to zones and still having my firmware work.

I used the following settings. Is this correct for the 28388D? I'm testing using the development kit. The CSM passwords are default values.

---
      .sect "dcsm_zsel_z1"
      .retain

    .long 0xFFFFFFFF     ;Z1 OTP CSM PSWD 0 (LSW of 128-bit password)
    .long 0x4D7FFFFF     ;Z1 OTP CSM PSWD 1
    .long 0xFFFFFFFF     ;Z1 OTP CSM PSWD 2
    .long 0xFFFFFFFF     ;Z1 OTP CSM PSWD 3 (MSW of 128-bit password)

;// Set Grab Flash Sectors and RAM for Zone Select Block 1 (repeating 01 bits = 0x5 (0101))
;// See Table 6-1 in 2838x TRF
    .long 0x05555555     ;Z1 OTP GRABSECT 1 (CPU1 Flash sectors 0 to 13)
    .long 0x05555555     ;Z1 OTP GRABSECT 2 (CM Flash sectors 0 to 13)
    .long 0x05555555     ;Z1 OTP GRABSECT 3 (CPU2 Flash sectors 0 to 13)
    .long 0x00055555     ;Z1 OTP GRABRAM 1 (CPU1 D1, D0, LS7-LS0 RAMs)
    .long 0x55555505     ;Z1 OTP GRABRAM 2 (MSG + CM C1 and C0 RAMs)
    .long 0x00055555     ;Z1 OTP GRABRAM 3 (CPU2 D1, D0, LS7-LS0 RAMs)

---

Note, that there were 2 .retain lines right after the .sect line. I fixed this, but I want to ensure that everything is going in Zone Block 1 for now to ensure that this was not the only mistake. 

  • Hi Wesley,

    Your GRABSECT values have an issue. The 2-bit field encoding 01 assigns a sector/RAM to Zone 1, which is correct — but your GRABSECT values use 0x05555555, not 0x55555555. That leading 0x0 matters.


    GRABSECT Fields

    Each flash sector uses a 2-bit field where 01 = Zone 1 1. Your pattern of repeating 01 bits is the right approach for assigning everything to Zone 1. However:

    • 0x05555555 = 0000 0101 0101 0101 0101 0101 0101 0101 — the top 4 bits are 00, not 01. This means the uppermost sector pair in each GRABSECT register has bits = 00, which is neither 01 (Zone 1) nor 10 (Zone 2). A value of 00 means those bits have been programmed to zero and cannot be changed back since OTP bits can only go from 1→0, never 0→1 2.

    • The correct value to assign all 14 sectors (sectors 0–13, using bits [27:0]) to Zone 1 should have 01 in every active 2-bit field. For 14 sectors that's 28 bits, so the correct value would be 0x05555555 if only bits [27:0] are used and bits [31:28] are reserved/unused. Check Table 6-1 in the TRM carefully to confirm which bit positions correspond to actual sectors versus reserved fields for each GRABSECTx register.


    Your GRABRAM values are more concerning:

    Register Your Value Observation
    GRABRAM1 0x00055555 Top bits are 0x000 — verify reserved field width vs. active fields
    GRABRAM2 0x55555505 The 05 in bits [7:0] means bits [7:6] = 00 and bits [5:4] = 01 — this leaves CM C0RAM with bits = 00
    GRABRAM3 0x00055555 Same pattern as GRABRAM1

    The TI DCSM example uses 0x0AAAAA09 for Z1_GRABRAM2 and 0x0AAAAA06 for Z2_GRABRAM2 3. Your 0x55555505 for GRABRAM2 differs significantly from the example pattern. The 05 in the low byte suggests CM C0RAM may have been assigned incorrectly or left with 00 bits.

    Critical: If both Zone 1 and Zone 2 GRAB bits for a block end up as 00 (or any non-01/10 combination), that memory becomes inaccessible when CSM passwords are programmed — even with default-like passwords 1. This would explain your unresponsive board if your firmware relies on those RAM blocks.


    Recovery Path

    1. Advance the LINKPOINTER: Since OTP is one-time programmable, you cannot fix the current ZSB. Program the LINKPOINTER to the next value (e.g., 0x3FFE) to activate a fresh Zone Select Block with correctable fields 2.

    2. Use the DCSM Security Tool (SysConfig): It auto-generates validated .asm and .cmd files and flags misconfigurations before you burn OTP 4. This is strongly recommended over hand-editing assembly.

    3. Reference the C2000Ware DCSM example at C2000Ware/driverlib/.../examples/.../dcsm/ — specifically dcsm_ex1_f2838x_dcsm_zxotp.asm for known-good values 3.

    4. To regain JTAG access now: Try forcing the device into wait-boot mode before connecting the debugger, then unlock using the On-Chip Flash tool with your CSM password 5.


    1. TMS320F28388D TRM — DCSM GRAB field encoding
    2. E2E: TMS320F28388D CSM Password / LINKPOINTER recovery
    3. TMS320F28388D TRM — DCSM Example Configuration
    4. SPRACP8A — C2000 DCSM Security Tool Application Note
    5. E2E: TMS320F28388D Secure Code Access Recovery

    Best Regards,

    Zackary Fleenor