TMS320F280039C: Support Required for TMS320F280039C Security Lock / DCSM Configuration

Hello Gowtham,

Thank you for reaching out regarding the DCSM security configuration issue on your TMS320F280039C device. I understand you're experiencing a lockout situation after programming OTP security sections. Let me provide detailed guidance on your questions.

Based on your description, it appears the device has been permanently locked by programming the Zone Header OTP sections, particularly if JTAGLOCK was enabled. Unfortunately, if JTAG access has been disabled at the hardware level through OTP programming, the device cannot be recovered. The Zone Header is a one-time programmable section that cannot be reversed or updated once written.

If you still have JTAG connectivity, there may be a possibility to update the LINKPOINTER to a new location with corrected configuration, but this is unlikely given your symptoms.

1. Correct Procedure for Implementing Code Protection Using DCSM

The TMS320F280039C DCSM provides two independent security zones (Zone 1 and Zone 2), each protected by a 128-bit password. The proper implementation sequence is:

Phase 1: LINKPOINTER Configuration (Updatable)

- Configure zone passwords (four 32-bit words per zone)

- Set GRABSECT registers to allocate Flash sectors to zones

- Set GRABRAM registers to allocate RAM blocks to zones

- Configure EXEONLY protection for code sections requiring execute-only access

Phase 2: Zone Header Configuration (One-Time Only - Use with Extreme Caution)

- JTAGPSWDH (JTAG password)

- JTAGLOCK settings

- Boot configuration options

The critical distinction is that LINKPOINTER configuration can be updated by programming subsequent LINKPOINTER locations, while Zone Header configuration is permanently set once programmed.

Password Match Flow (PMF) for Unlocking:

To unlock a secured zone during runtime, your code must write all four 32-bit password words to the CSMKEYx registers in sequence. This unlocks the zone for the current power cycle.

2. Recommended Method for Securing Firmware in Mass Production

Development and Testing Phase:

1. Develop and test all code in RAM without any Flash security enabled
2. Test security configuration using LINKPOINTER method only
3. Verify that your unlock procedure works correctly
4. Test on multiple development devices before moving to production

Pre-Production Phase:

1. Program LINKPOINTER configuration with zone passwords
2. Allocate Flash sectors using GRABSECT registers
3. Verify firmware update mechanisms function correctly
4. Test on pilot production batch

Production Phase:

1. Program LINKPOINTER configuration with production passwords
2. Enable EXEONLY protection for critical code sections
3. Do NOT program Zone Header unless absolutely required for your security model
4. Maintain detailed password documentation in secure storage

Critical Recommendations:

- Use the C2000 DCSM Security Tool available in C2000Ware and integrated into Code Composer Studio via SysConfig. This tool helps prevent common configuration errors.

- Never enable JTAGLOCK during development or testing

- Keep at least one "golden" device permanently unlocked for development purposes

3. Proper Usage of Zone1/Zone2 Passwords and EXEONLY Configuration

Password Configuration:

- Each zone requires a 128-bit password consisting of four 32-bit words

- Default value (all 0xFFFFFFFF) leaves the zone unsecured

- Any other value secures the zone and requires password match flow to unlock

- Store passwords securely and maintain backup documentation

EXEONLY Configuration:

- EXEONLY provides execute-only protection for Flash sectors

- Code can execute from EXEONLY regions but cannot be read, even by debugger

- Applied per Flash sector allocated to a zone

- Provides additional protection layer beyond zone passwords

Zone Allocation Strategy:

- Zone 1: Critical application code with EXEONLY protection

- Zone 2: Less critical code or calibration data

- Unsecure regions: Public or shared resources

GRABSECT Register Values:

- 00b: Invalid (sector inaccessible)

- 01b: Allocate sector to this zone

- 10b: No request for sector

- 11b: No request when unlocked; inaccessible when locked

4. OTP/JTAG Lock Settings - What to Program and What to Avoid

Safe to Program (Updatable via LINKPOINTER):

- Zone passwords (Password 0-3 for each zone)

- GRABSECT registers (Flash sector allocation)

- GRABRAM registers (RAM block allocation)

- EXEONLY configuration bits

- Zone Control Register settings

Program Only in Final Production (One-Time Only - Cannot Update):

- Zone Header OTP sections:

- JTAGPSWDH (JTAG password high bits)

- JTAGLOCK (permanently disables JTAG)

- Boot configuration bits

JTAGLOCK Critical Warning:

When JTAGLOCK is programmed, JTAG access is permanently and irreversibly disabled. The device becomes unrecoverable through JTAG if any firmware issues occur. Only enable JTAGLOCK if your application has the highest security requirements and you have thoroughly tested all firmware functionality.

Root Cause of Your Issue:

The symptoms you describe indicate that Zone Header OTP sections were programmed, likely including JTAGLOCK. This is the most common cause of permanent device lockout during DCSM configuration.

5. Device Recovery Possibilities

Given that you cannot connect through JTAG/debug tools, the device has likely been permanently locked through JTAGLOCK programming in the Zone Header. This cannot be reversed.

Potential Recovery Scenarios (Low Probability):

If JTAG is still accessible:

- Attempt to program the next available LINKPOINTER location with corrected configuration

- This requires that Zone Header was not programmed

If you have the correct password and code execution is possible:

- Implement Password Match Flow in your bootloader

- Write the correct password sequence to unlock the zone

- This requires the device to boot and execute code

Realistic Outcome:

Based on your description of complete JTAG/debug tool connectivity loss, the device is permanently locked and cannot be recovered. This device should be discarded, and new devices should be configured following the corrected procedure outlined in this response.

Best Practices to Avoid Permanently Locking Devices During Production:

1. Never program Zone Header OTP sections during development or testing
2. Use only LINKPOINTER-based configuration until final production
3. Always test security configuration in RAM before Flash programming
4. Use the DCSM Security Tool in CCS/SysConfig to generate configuration code
5. Maintain at least one permanently unlocked "golden" device for development
6. Document all passwords securely with backup copies
7. Test unlock procedures thoroughly before production deployment
8. Implement a bootloader with password unlock capability for field updates
9. Never enable JTAGLOCK unless your security requirements absolutely demand it
10. Test on pilot production batch before mass production deployment

Staged Security Implementation:

- Stage 1 (Development): No security enabled

- Stage 2 (Testing): LINKPOINTER with passwords only

- Stage 3 (Pre-Production): Add EXEONLY protection

- Stage 4 (Production): Optionally add Zone Header (if required)

Recommended Secure Production Flow

For your future production devices, implement security as follows:

Step 1: Use DCSM Security Tool

- Launch Code Composer Studio

- Open your project and access SysConfig

- Configure DCSM settings using the graphical tool

- Generate configuration code automatically

Step 2: Configure LINKPOINTER Only

- Set unique 128-bit passwords per device or product line

- Allocate Flash sectors to Zone 1 using GRABSECT

- Enable EXEONLY for critical code sections

- Leave Zone Header unprogrammed (all 0xFFFFFFFF)

Step 3: Implement Unlock Function in Bootloader

Your application code should include a function to unlock the zone when needed:

void UnlockZone1(void) {
DCSM_Z1_CSMKEY0 = Zone1_Password[0];
DCSM_Z1_CSMKEY1 = Zone1_Password[1];
DCSM_Z1_CSMKEY2 = Zone1_Password[2];
DCSM_Z1_CSMKEY3 = Zone1_Password[3];
// Zone 1 is now unlocked for this power cycle
}

Step 4: Verify on Test Devices

- Program security configuration on test devices

- Verify firmware can be updated

- Verify unlock procedure works correctly

- Test complete production programming flow

Step 5: Production Deployment

- Program LINKPOINTER configuration only

- Do not enable JTAGLOCK

- Maintain password documentation

- Implement field update capability through bootloader

Technical Resources

1. C2000 DCSM Security Tool Application Report (SPRACP8A) - www.ti.com/.../spracp8a.pdf
2. Enhancing Device Security by Using JTAGLOCK Feature Application Report - www.ti.com/.../spracs4.pdf
3. TMS320F280039C Technical Reference Manual - Chapter 5: DCSM - www.ti.com/.../spracp8a.pdf
4. C2000 Unique Device Number Application Report - www.ti.com/.../spracd0b.pdf

These documents provide detailed information on DCSM architecture, configuration procedures, and security best practices.

Summary and Next Steps

Current Situation:

Your device is permanently locked due to programming Zone Header OTP sections. This cannot be reversed, and the device cannot be recovered.

Recommended Actions:

1. Discard the locked device
2. Obtain new development devices for testing
3. Install and use the DCSM Security Tool from C2000Ware
4. Follow the recommended flow outlined above, using LINKPOINTER configuration only
5. Test thoroughly on development devices before production deployment
6. Never program Zone Header or enable JTAGLOCK during development

For Production:

- Use LINKPOINTER-based security with zone passwords

- Enable EXEONLY for critical code sections

- Implement bootloader with unlock capability

- Maintain detailed password documentation

- Test on pilot batch before mass production

If you need additional assistance with implementing the DCSM Security Tool or have questions about the configuration process, please let me know.

Best Regards,

Zackary Fleenor