topic Re: S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC in S32K

S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC

EddiePark — Mon, 11 May 2026 03:42:33 GMT

Environment:
- Device: S32N55 EVB
- HSE FW: 1.0.24.0
- GrayVIP: 1.0.22
- T32: [버전]
- LC: OEM_OPEN

Symptoms:
ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID, 52U) is programmed (confirmed via
GetAttribute → SHA3_384 hash returned).
However, CHIP.SecureChallenge(0) in Lauterbach T32 returns
"device unlock failed".

CMM sequence:
SYStem.Down
SYStem.CPU S32N55-M7-FSS
SYStem.CONFIG DEBUGPORTTYPE JTAG
SYStem.Option DUALPORT ON
SYStem.MemAccess DAP
SYStem.JtagClock 10MHz
SYStem.Mode PREPARE
&UID0=FORMAT.HEX(16.,CHIP.SecureChallenge(0)) ← fails here

Questions:
1. Is CHIP.SecureChallenge() expected to work on OEM_OPEN LC,
or is OEM_CLOSED required?

2. Is MCK (HSE_OTP_FOEM_MCK_ATTR_ID, 51U) required before
CHIP.SecureChallenge() can generate a Challenge?

3. What is the exact prerequisite for CHIP.SecureChallenge()
to return a valid Challenge on S32N55?

4. Is volkano.exe (SDAF package) required for Response calculation,
or can it be implemented with AES-ECB using ADKP directly?

Re: S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC

EddiePark — Mon, 11 May 2026 07:01:53 GMT

Additional questions:

5. CHIP.SecureChallenge(0) reads UID[63:0] according to T32 documentation.
The fact that even UID reading fails with "device unlock failed" suggests
SDC-600 handshake itself is not completing.
Does T32 CHIP.SecureChallenge() automatically handle the SDC-600
Init sequence (LPH2RA_FLAG, IDR_FLAG, Protocol ID) and
Start Command (0x00, 0xEB, 0xCD, 0x5D)?
Or does this need to be triggered manually before calling
CHIP.SecureChallenge()?

6. Is ODAK (HSE_OTP_FOEM_ODAK_ATTR_ID, 54U) required in addition to ADKP
for Challenge-Response mode?
Currently only ADKP (52U) is programmed.

7. What OTP keys are required to be programmed before
CHIP.SecureChallenge() can return a valid Challenge on S32N55?
(MCK=51U, ADKP=52U, ODAK=54U?)

Re: S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC

chenyin_h — Mon, 11 May 2026 08:46:35 GMT

Hello, @EddiePark

Thanks for your post.

1. Regarding with the questions raised, as what my colleague had mentioned in your another thread, in the NXP community we can only help you with fully launched products, but S32N55 is still a pre-production chip, I suggest contacting your NXP representative/distributor for closer help for urgency topics.

2. Since currently there is still no S32N board in community, I suggest posting new threads in S32G instead of this board next time.

3. I will try investigating and collecting some inputs internally for your issues if possible, but it may take some time and may not fully solve your issue, I apologize in advance.

Chenyin

Re: S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC

chenyin_h — Mon, 11 May 2026 10:44:35 GMT

Hello, @EddiePark

Under OEM_OPEN LC, the FSS is open to the debug capabilities by default, secure debug is not needed for accessing FSS.

Chenyin

Re: S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC

EddiePark — Mon, 11 May 2026 10:50:08 GMT

Thank you for your response, Chenyin.

I understand that under OEM_OPEN LC, debug access is granted
by default without authentication.

However, I have a follow-up question:

CHIP.SecureChallenge(0) is supposed to read UID[63:0],
which should be accessible regardless of LC state.
But it returns "device unlock failed" even under OEM_OPEN.

Is this expected behavior?
If so, how should we read the UID (128-bit) and Challenge
(256-bit) for future OEM_CLOSED testing without
CHIP.SecureChallenge()?

Thank you.

Re: S32N55 CHIP.SecureChallenge() returns "device unlock failed" on OEM_OPEN LC

chenyin_h — Wed, 13 May 2026 14:51:09 GMT

Hello, @EddiePark

Thanks for your reply.

1. Currently, from available S32N55 documentation released, I feel sorry that it is still lacking of details for the secure debug topic, thus we may not provide accurate feedback in short period.

2. As what we had mentioned, the S32N55 is still in pre-production phase, it is currently not targeted supporting it via the community, I suggest directly contacting your NXP representative for further support.

Truly apologize for your inconvenience.

Chenyin