TMS320F280033: DCSM/OTP Programming Error (FMSTAT 0x30) Bricking Device

Part Number: TMS320F280033
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am working with an F280033 device and attempting to configure the DCSM (Zone 1) using SysConfig. My goal is to secure the device, including enabling JTAG Lock (Password Match mode), configuring the Link Pointer, and setting up CSM passwords.

However, when I attempt to flash the configuration generated by SysConfig, the programming operation fails with an error, and the device appears to be bricked (I can no longer connect or recover it).

Error:

[28/1/2026, 17:35:03] [ERROR] C28xx_CPU1: Error during Flash Programming. Address 0x00078020, FMSTAT (STATCMD on some devices) 0x00000030
[28/1/2026, 17:35:03] [ERROR] C28xx_CPU1: File Loader: Memory write failed: Unknown error

My .syscfg settings below (with passwords redacted).

I am configuring:



DCSM1.$name = "DCSM0";
DCSM1.ZONE1_OTP.configureBoot = true;
DCSM1.ZONE1_OTP.BOOTDEF0 = "0x23"; // Flash Entry
DCSM1.ZONE1_OTP.JTAGLOCK = true;   // Enable JTAG Lock
DCSM1.ZONE1_OTP.bootPinCount = 0;

/* JTAG Passwords (High) - Masks applied */
DCSM1.ZONE1_OTP.JTAGPSWDH0 = "0x4BXXXXXX"; // Redacted
DCSM1.ZONE1_OTP.JTAGPSWDH1 = "0x3FXXXXXX"; // Redacted

/* CSM Passwords & JTAG Low - Masks applied where necessary */
DCSM1.ZONE1.PASSWORD0 = "0xXXXXXXXX";
DCSM1.ZONE1.PASSWORD1 = "0x4DXXXXXX"; // Mask applied for LinkPointer
DCSM1.ZONE1.PASSWORD2 = "0xXXXXXXXX";
DCSM1.ZONE1.PASSWORD3 = "0xXXXXXXXX";

DCSM1.ZONE1.JTAGPSWDL0 = "0xXXXXXXXX";
DCSM1.ZONE1.JTAGPSWDL1 = "0x2BXXXXXX"; // Mask applied

/* Memory Security */
DCSM1.ZONE1.RAMLS0 = "SECURE";
// ... (All RAMLS and Flash Sectors set to SECURE)

Since this is an OTP programming operation, I suspect I might be triggering a security violation or trying to overwrite an already programmed bit, but this is a fresh device.

Could you please advise on:

  1. What specifically triggers FMSTAT 0x30 at address 0x78020 on F28003x?

  2. Is there any recovery method for a device in this state (JTAG locked but potentially failed OTP write)?

  3. Could you please review my SysConfig settings? specifically, did I make any mistakes in the configuration of the masks (for LinkPointer and JTAG Lock bits) that could be causing the programming tool to reject the write command?

Thank you for your support.

Best,

Luca

  • Hello Luca,

    What specifically triggers FMSTAT 0x30 at address 0x78020 on F28003x?

    FMSTAT 0x30 means that the user attempted to program a “1” where a “0” was already present. 

    Is there any recovery method for a device in this state (JTAG locked but potentially failed OTP write)?

    Please configure the device for wait boot and attempt to unlock the JTAG (by inputting the default JTAG passwords in the ccxml). You can refer to this application note for details: https://www.ti.com/lit/an/spracs4/spracs4

    It is possible that only JTAGPSWDH0/JTAGPSWDH1 got programmed (since JTAGPSWDL0/JTAGPSWDL1 is in the ZSB), so you can try using only the upper half of the passwords.

    Could you please review my SysConfig settings? specifically, did I make any mistakes in the configuration of the masks (for LinkPointer and JTAG Lock bits) that could be causing the programming tool to reject the write command?

    The issue may be that JTAGLOCK is being engaged during programming due to the Flash tool’s “Verify” setting in CCS. On older devices (F28x7x, F28002x, F28004x, etc.), JTAGLOCK activates after reset. On more recent devices (including F28P55x/P551x), JTAGLOCK activates on subsequent read to the Z1OTP_JLM_ENABLE register in OTP.

    Please refer to the TRM:

    After CCS programs the Z1OTP_JLM_ENABLE register, it verifies the data is correctly programmed which issues a read to Z1OTP_JLM_ENABLE. Consequently, JTAGLOCK is activated and the programming is interrupted.

    Please try disabling “Verify Flash after Program” in the On-Chip Flash tool before attempting to program the DCSM configurations:

    1. Uncheck “Verify Flash after Program”

    After the customer successfully programs their JTAGLOCK configs with flash verify disabled, they can re-connect with the JTAG passwords in the target configuration .ccxml (therefore disabling JTAGLOCK) and re-program the same firmware WITH flash verify enabled. This allows the customer to verify their program was successfully programmed. This is possible now because JTAGLOCK is disabled in the debug session (via the ccxml).

    I will be out-of-office for the rest of the week, so I will loop in my colleague to address any further concerns.

    Best,
    Matt

  • Hello,

    Closing this thread as it's been a month with no reply, assuming resolved.

    Best,
    Matt