CC2340R5: Questions on CC2340 Debug Access Security (CCFG) Configuration and J-Link Unlock Procedure

Hello TI Team,

I am evaluating the Debug Access security mechanism on the CC2340R5, specifically focusing on the combined behavior of the permissions.allowDebugPort and debugCfg.authorization fields in the CCFG area. I have encountered some procedural questions when using J-Link Commander for both debugging and access recovery, and I would appreciate your official guidance.

My CCFG configurations are primarily discussed in the context of the following two scenarios:

Question 1: J-Link Unlock Procedure under Password Protection Mode

Configuration Status:

• CCFG.permissions.allowDebugPort = CCFG_PERMISSION_ALLOW

• CCFG.debugCfg.authorization = CCFG_DBGAUTH_REQPWD (Require Password Authentication)

Problem Description:

If my device is programmed and has the AHB-AP (CPU core) locked according to the above configuration, and I know the cleartext password required for unlocking is "Open Sesame!".

1. Is there an officially recommended or simplified command sequence for J-Link Commander to submit this password via the SACI interface and successfully acquire debug access?

2. I understand the process requires switching to the SEC-AP (AP #2) and then writing the password as Little-Endian 32-bit words. Could you provide a complete and reliable step-by-step procedure/script for J-Link Commander to complete the unlock process without relying on TI-specific tools (such as CCS or UniFlash)?

Question 2: Non-Erase Recovery Method in DBGFORBID State

Configuration Status:

• CCFG.permissions.allowDebugPort = CCFG_PERMISSION_ALLOW (Allow SWD Port)

• CCFG.debugCfg.authorization = CCFG_DBGAUTH_DBGFORBID (Debug Forbidden)

Problem Description:

Based on the TRM documentation, under this configuration, the SWD interface remains active, and the device is able to enter SACI mode.

1. In this Debug Forbidden but not physically disabled state, aside from executing the Chip Erase command (CMD 0x09) via the SACI interface, is there any other non-destructive method to temporarily or permanently regain debug access to the chip? For example, is there a special SACI command or DP/AP register operation that can bypass the DBGFORBID restriction?

2. We aim to retain a recovery method that is only accessible to TI or authorized users (if such a method exists) while securing the device, without risking data loss (Chip Erase). If no such method exists, does it mean that as long as allowDebugPort is not set to FORBID, Chip Erase is the only available recovery option?

I look forward to your professional guidance and clarification.

Thank you!