• 状态 TI Thinks Resolved
  • 回复 3 回复
  • 答案 1 答案
  • 订户 10 订户
  • 视图 73 视图
  • 用户 0 会员在此处
选项
选项
相关

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

Qingtian Yang
Prodigy 30 points
Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH

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!

  • 0
    TI__Mastermind 34000 points

    Hello!

    We have received your case and will take some time. Thank you for your patience.

  • 0
    TI__Mastermind 34000 points

    Question 1:

    You will find a complete Connect to CPU procedure of the AP Domain in Figure 8-5 of the TRM.   You can particularly follow SACI_CMD_DEBUG_REQ_PWD_ID and SACI_CMD_DEBUG_SUBMIT_AUTH in Chapter 8 for additional details.  You can also refer to the Arm Debug Interface Architecture Specification.

    Question 2:

    If CCFG.permissions.allowDebugPort is CCFG_PERMISSION_ALLOW but CCFG.debugCfg.authorization is CCFG_DBGAUTH_DBGFORBID then you are able to enter the SWD port to the CFG-AP and SEC-AP access points from boot to allow device IDs and information to be read out through CFG-AP and communication with SACI through SEC-AP, but not the AHB-AP access point that us used by debug probe can be enabled before the bootloader is invoked or the application is invoked using CCFG configurations.  Without the AHB-AP you will not be programming or accessing the device memory.  Having the debug authentication password is the best way to allow only authorized users to the memory stored on the device.

  • 0 回复 Links
    Prodigy 30 points

    Thank you for your detailed response and clarification.

    Regarding Question 2, I have successfully understood your explanation.

    However, regarding Question 1 (Password Authentication using J-Link), while you pointed us to the relevant documentation, the manual process of switching APs and writing registers within the J-Link Commander environment is proving to be extremely *** and prone to error in real-world use.

    To quickly validate the entire password authentication procedure and its expected behavior, could you please provide a simple operational guide using the official TI development kit (e.g., CCS or UniFlash with an XDS110 debugger) to perform the password authentication on CC2340?

    If the official TI tools have a feature that handles this process automatically, it would serve as an effective validation benchmark. Once we confirm the correct authentication process using the official tools, I can then use them to validate my product and even explore the implementation of the same function using J-Link.

    We look forward to your continued support. Thank you!