KW45: Debug Authentication Fails with SPSDK 3.1.0 & J-Link on Secured Device (Wrong DM-AP IDCODE)

[JabezLaw]

Hello NXP Team,

I am developing a mass production flow for the KW45B41Z83A, following AN14003. While my SB3 generation and flashing process is working, I am facing a critical issue with the Debug Authentication flow that I believe is caused by an incomplete fuse provisioning sequence.

Environment:

• MCU: KW45B41Z83A on KW45B41Z-EVK board

• Probe: On-board MCU-Link flashed with J-Link firmware

• SPSDK Version: 3.1.0

• J-Link Version: V8.12a

Problem Description: The target board for this test is in the OEM SECURE WORLD CLOSED state. When I run the nxpdebugmbox -i jlink dat auth command, the cryptographic handshake appears to succeed (the DAC/DAR exchange is logged correctly, and RoT Hashes match), but the command ultimately fails with Access to AHB is not granted. A subsequent connection attempt with J-Link Commander fails with ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF.

Critical Information about the Target Board's Provisioning: The board was moved to the OEM SECURE WORLD CLOSED state using an incomplete procedure. My colleague executed only the first command from a sequence recommended in another Application Note (AN14158):

1. blhost -p COMX fuse-program 0xa 0xf was executed to advance the lifecycle.

2. Crucially, the board was manually reset immediately after this command.

3. The subsequent fuse-program commands from the sequence to program TZM_EN (fuse 0xd), SB3KDK (fuse 0x20), and RoTKTH (fuse 0x1f) were skipped.

As a result, the board is in a SECURE lifecycle state but is likely missing other critical fuse configurations required by the ROM for proper operation in this state.

My Core Question: Could this incomplete provisioning procedure (advancing the lifecycle to OEM SECURE WORLD CLOSED without programming the TZM_EN fuse, etc.) be the root cause of the Access to AHB is not granted error? Does the ROM bootloader's debug authentication mechanism depend on these other fuses being correctly set, even if the cryptographic portion of the authentication succeeds?

This seems to be the most likely cause, as all my keys, certificates, and cc_socu configurations have been verified to be correct.

I am preparing to provision another OEM OPEN board using the complete, correct procedure, but I would appreciate your expert confirmation on this matter. I will attach my configuration files and the key log files for your reference.

Thank you for your guidance.

Attached are debug log info：

[Sabina_Bruce]

@JabezLaw 

Glad to hear you got it working!

Just as a final comment you can continue using the SEC tool it is also possible to go to production with the scripts it generates automatically. Of course the main change i would suggest would be to change the keys. You can generate new keys or import your production keys(just use the same naming convention as the tool so it recognizes them)... if you are using an HSM and dont have access to the private keys directly you can also connect to your HSM with our signature provider to make that seamless and only provide your public keys. 

[Sabina_Bruce · Accepted solution]

Hi @JabezLaw 

I tested your dat_config.yaml directly as we have the same keys on the EVKs. It works on my end. 

I would check the following:

1. Does your device boot normally? i.e. sign an image and boot normally hello world or blinky

2. While application is running attempt to go to debug authentication again. Make sure device is not in ISP mode. 

3. Do you have another EVK you can test on? If so, before testing on this EVK test on your current EVK by advancing the lifecycle to Closed and see if the behavior differs.  

4. If you want to retest on new EVK I would recommend using the SEC GUI tool as it will signal any errors or warnings before programming fuses this can be useful in identifying anything that may have been missed with the SPSDK command line tool. 

You can import the keys used by the EVK easily by Import keys button and head to the path in your PC "C:\nxp\MCUX_Provi_25.06\bin\_internal\data\sample_data\targets\K32W148" this contains a board_example_keys folder for KW456 and K32W148. 

[JabezLaw]

Hi @Sabina_Bruce ,

Great news! I wanted to follow up and let you know that the issue is now resolved.

Your suggestion to use the SEC GUI Tool was the key to success. I used it to provision a fresh OEM OPEN board, and the tool guided me through the process flawlessly.

I can confirm that the board is now successfully in the OEM CLOSED lifecycle state, and more importantly, the Debug Authentication process works perfectly using my existing scripts and configurations.

Thank you so much for your invaluable support and guidance. I couldn't have solved this without your help.

Best regards,

Jabez

[Sabina_Bruce]

Hi @JabezLaw 

When you set it CC_SOCU to 0x0000 you are disallowing the "certificate holder" from acquiring any access rights that are allowed in the device. 

This is so that you can for example allow all ports to be open, but you want technician A to only debug a certain port and technician B to only debug a different port so you can further allow or disallow their access rights. Setting 1 on a specific bit field, means that it will follow the device's security level for that field and setting a 0 on a specific bit field will disallow access despite the device's security level. 

The main difference I see in your workspace compared to mine is the lifecycle stage. Are you testing a second development stage? The secure world closed is not a recommended final production lifecycle, however this not prevent a successful debug authentication session. Though it is the main difference I notice. 

Here is my result on my end:

There are no other fuses that need to be burned in order for debug authentication to work. 

If you can zip up your workspace and add it here, I can test your workspace.

[JabezLaw]

Hi @Sabina_Bruce,

Thank you so much for the detailed explanation of the CC_SOCU bitmask. This is incredibly helpful and clarifies how the debug credential acts as a filter on top of the device's fused security policy. Your interpretation makes perfect sense.

As you offered, I have prepared my complete workspace for you to test on your end. I have cleaned up the folder and translated all the comments in the Jupyter Notebook script into English for your convenience.

You can find the zipped workspace attached to this post. The main script's path is " KW45_Debug_Auth_Workspace_JabezLaw\sb\kw45xx_k32w1xx\debug_authentication_kw4s.ipynb".

Best regards,

Jabez

[Sabina_Bruce]

Hi @JabezLaw 

Looking at your DC_CONFIG.YAML you are setting CC_SOCU to all 0x0 effectively disabling/disallowing all debug ports. The bit mask should be 0xFFFF to enable all. Can you please retry with this modification. Also make sure to do POR between attempts, if an unsuccessful debug session was attempted then it will continue showing as unsuccessful until POR.

[JabezLaw]

Hi @Sabina_Bruce ,

Thank you for your suggestion. I appreciate you taking the time to look into this.

I have followed your advice precisely. I modified my dc_config.yaml to set cc_socu: '0xFFFF', regenerated the debug credential, performed a full Power-on Reset (POR) on the OEM SECURE WORLD CLOSED board, and then re-ran the authentication command.

Unfortunately, the result is identical to my previous attempts. The cryptographic handshake appears to succeed, but the process fails at the final step with the exact same error: Access to AHB is not granted.

This outcome aligns with my understanding of the KW45 security model as described in Table 91 of the Security Reference Manual (KW45SRM). My interpretation is:

• The device's fuses (DCFG_CC_SOCU_L1 = 0x00000000) configure the debug domains to Level 1 (disabled by default, but can be enabled via authentication).

• Setting cc_socu to 0xFFFF in the debug credential creates a request for Level 0 access (always enabled).

This seems to create a logical conflict between the requested permission and the device's actual fused state, which would correctly result in a failure.

Since both a logically correct request (cc_socu: '0x0000') and a max-privilege request (cc_socu: '0xFFFF') lead to the same Access to AHB is not granted error, it strongly suggests the issue is not with the cc_socu value itself.

The core problem seems to be that the ROM is deciding not to grant AHB access even after the cryptographic portion of the authentication is successful.

Could there be another fuse setting or a prerequisite that we are missing, which acts as a master gate for granting AHB access in a secure lifecycle state?

I have attached the log file from the latest test using cc_socu: '0xFFFF' for your analysis. Any further insights you can provide would be greatly appreciated.

Best regards,

Jabez

[nxa17177]

Hello @JabezLaw, 

first of all: programming the TZM_EN fuse is not necessary. This had to be done on the very first samples (do you have such samples?), but programming the TZM_EN fuse can now be completely removed from all scripts, as it is now always done by NXP.

In any case, if you didn't set up trust-zone, then everything is secure.

In my opinion, the device is unusable and cannot be easily recovered. Primarily, an unburned RoTKTH fuse causes a debug authentication error. Without RKTH, nothing can work. 

The fundamental step is to advance the lifecycle only after both SB3KDK (fuse 0x20) and RoTKTH (fuse 0x1f) have been programmed.

Please let me know if you run into any problems when following the complete procedure with the new board.

[JabezLaw]

Hello NXP Team,

Thank you for your reply and for the valuable information regarding the TZM_EN fuse.

To clarify my setup, I am using the official KW45B41Z-EVK, which comes with the default RoTKTH and SB3KDK fuses pre-programmed. My successful SB3 flashing operations and the matching hash in the DAC response confirm my keys are correct.

Based on the investigation so far, it appears the test board I was using was put into an insecure, incomplete state. I will set that board aside.

I am now preparing to provision a fresh OEM OPEN board and would like to ask for your confirmation on my planned end-to-end procedure to ensure I do not create another unrecoverable device.

Here is my plan:

Step 1: Provision the Device I will use nxpimage sb31 export to generate an SB3 file with the following commands in my sb3_config.yaml to correctly configure the device and advance its lifecycle in a single, atomic operation:

YAML

commands:
  # Program the debug permission fuse for L1 (S-World)
  - programFuses: { "address": "0x22", "values": "0x00000000" } 
  # Advance lifecycle to OEM Secure World Closed
  - programFuses: { "address": "0x0A", "values": "0x0F" }

Step 2: Authenticate the Secured Device After flashing the above configuration and power cycling the board, I will use a dc_config.yaml with cc_socu: '0x0000' to generate the debug credential. My probe is an MCU-Link running J-Link firmware. I will then perform the authentication with the following command:

Bash

nxpdebugmbox -i jlink -v dat auth -c my_dat_config.yaml

Step 3: Connect with J-Link Commander Immediately after the auth command, without resetting the board, I will attempt to connect using J-Link Commander.

My Core Question: Before I permanently program a new board, could you please confirm if this complete, three-step procedure is the correct and intended way to enable and use Debug Authentication on the KW45?

Am I missing any other critical fuse settings or steps that would cause the final J-Link connection to fail with the Wrong DM-AP IDCODE error?

Thank you for confirming the correct path forward.

Best regards,

[JabezLaw]

Hello @nxa17177 

Just a friendly follow-up on my post from last Wednesday.

I am preparing to program a new OEM OPEN board and would be very grateful for your confirmation on the end-to-end provisioning and authentication procedure I outlined. Your guidance here is crucial for us to avoid creating another unrecoverable device and to move forward with our project.

We understand you are busy, but any insights you could provide would be greatly appreciated.

Thank you again for your support.

Best regards,

Jabez

[nxa17177]

Please look into https://www.nxp.com/products/KW45?tid=vanKW45#documentation for: Debug Authentication on KW45/K32W148[AN14158] and check your configuration files if needed. 

[nxa17177]

Hello @JabezLaw , could you please also share the content of the: 

my_dat_config.yaml

? 

[JabezLaw]

Hello  @nxa17177,

Thank you for looking into this. Here are the configuration files and the exact steps I'm using to generate my debug credentials and attempt authentication.

---

Step 1: Generate the Debug Credential Key (DCK)

First, I generated a secp384r1 key pair for the debugger (DCK) using the following command:

Bash

nxpcrypto key generate -k secp384r1 --force -o keys/dck_keypair_384.pem

---

Step 2: Generate the Debug Credential (DC) Certificate

Next, I created the dc_config.yaml file to define the debug certificate. The configuration correctly uses the EVK's secp384r1 RoT keys for signing and points to the secp384r1 DCK public key generated in Step 1.

dc_config.yaml:

YAML

family: kw45b41z8
revision: latest
uuid: '00000000000000000000000000000000'
cc_socu: '0x0000'
cc_vu: 0
cc_beacon: 0

rot_meta:
  - ../../_data/keys/EVK_keys/RoT_key0_secp384r1_kw45xx.pub
  - ../../_data/keys/EVK_keys/RoT_key1_secp384r1_kw45xx.pub
  - ../../_data/keys/EVK_keys/RoT_key2_secp384r1_kw45xx.pub
  - ../../_data/keys/EVK_keys/RoT_key3_secp384r1_kw45xx.pub

rot_id: 0
dck: ../keys/dck_keypair_384.pub
signer: ../../_data/keys/EVK_keys/RoT_key0_secp384r1_kw45xx.pem

I then used this configuration to generate the final certificate file (debug_auth.bin) with the command: nxpdebugmbox dc export -c workspace/dc_config.yaml -o workspace/debug_auth.bin

---

Step 3: Attempt Debug Authentication

Finally, this is the dat_config.yaml I use with the nxpdebugmbox dat auth command. It points to the certificate generated in Step 2 and the DCK private key from Step 1.

dat_config.yaml:

YAML

family: kw45b41z8
revision: latest
certificate: workspace/debug_auth.bin
beacon: 0
srk_set: oem
signer: ../keys/dck_keypair_384.pem

I hope this detailed breakdown clarifies my procedure. Please let me know if you see any issues in this flow.

Thanks again for your help.

[nxa17177]

Hello @JabezLaw, have you found any inconsistency from https://www.nxp.com/products/KW45?tid=vanKW45#documentation for: Debug Authentication on KW45/K32W148[AN14158] in your flow?

[JabezLaw]

Hi @nxa17177,

Thank you for the follow-up and for pointing me to AN14158.

Yes, I have carefully reviewed AN14158 ("Debug Authentication on KW45/K32W148") again, and I can confirm that my workflow is fully consistent with the procedures outlined in section 5.5 ("Debug credentials and authentication").

To be precise, here is a summary of my validated process:

• Keys & Fuses are Correct: My RoT keys and SB3KDK are correct. This is proven by (1) my ability to successfully flash SB3 files (which depends on both keys) and (2) the matching RoTKTH reported by the device itself in the DAC response.

• Configurations are Correct: My dc_config.yaml correctly uses cc_socu: '0x0000', and the dat_config.yaml points to the correct certificate and secp384r1 private key.

• Toolchain is Correct: I am using the latest SPSDK (v3.1.0) with the -i jlink backend and the probe is flashed with J-Link firmware, as recommended.

Despite this correct setup, the process consistently fails at the final step. The log below clearly shows a successful cryptographic handshake, immediately followed by the failure.

Execution Log (nxpdebugmbox -i jlink -v dat auth ...):

INFO:spsdk.apps.nxpdebugmbox:Starting Debug Authentication
...
INFO:spsdk.apps.nxpdebugmbox:DAC: 
Version                : Version 2.1
SOCC                   : 0x00000005
UUID                   : F33B5C9F4E9D897FB8B55A95AA388692
ROTID_rkth_hash        : 650d8097079ff27a3e8a2da14781b922fd8295b6c00bfa067f00e87f1a16b8b3
...
INFO:spsdk.apps.nxpdebugmbox:============================================== DAC versus DC (Warning) ===============================================
...
  RoT Hash(Succeeded): 650d8097079ff27a3e8a2da14781b922fd8295b6c00bfa067f00e87f1a16b8b304bf710d45cbd591e2e24be83183922c
...
INFO:spsdk.apps.nxpdebugmbox:DAR:
...
Debug Authentication ends without AHB access.
SPSDKAppError: Debug Mailbox authentication failed: SPSDK: Problem with debug mailbox occurred: Access to AHB is not granted.

Since the cryptographic part of the authentication appears to succeed, the failure seems to be in the tool's final step of actually gaining bus access. My core question therefore remains:

What specific conditions within the KW45 ROM or the J-Link driver interaction would cause an Access to AHB is not granted failure after a successful cryptographic handshake?

This issue is the final blocker for our secure development workflow, and any specific insights you can provide on this specific AHB access problem would be extremely helpful.

Best regards, JabezLaw