S32N55 HSE2 CRS domain authentication does not complete Hello, We are implementing HSE2-based Secure Debug on S32N55 using the SDC-600 debug authentication flow (challenge/response, APP mode, AES-256-CMAC), driven from a T32 CMM host script talking to SDC-600 over the debug port. **Status** - **FSS domain**: Secure Debug authentication completes successfully. Debug target `0x1A` (FSS) returns `AUTHSTATUS = 0xBBB` after the challenge/response exchange, confirming the domain is unlocked. - **CRS domain**: Authentication does not complete. We use debug target `0x1B` for CRS (assumed, pending confirmation from the HSE2 FW Reference Manual — see question 1 below). **Observed behavior for CRS** 1. SDC-600 COMM_START and SoC Info exchange complete normally. 2. AUTH_MODE_REQ to target `0x1B` returns `AUTH_MODE = 0x0` (challenge-based), as expected. 3. APP_CHALLENGE request completes; a 32-byte challenge is received from the FW. 4. We compute the response as AES-256-CMAC over the challenge using the ADKP, and send the 16-byte `appChallengeAuth` response. This transmission completes without a transport-level error. 5. **At this point, the FW never sends `RxRESULT`.** The host script stalls waiting for the response in `rx_response_from_fw` — no `0xF2` (fail) and no ACK pattern, just no reply at all. This is different from a clean failure; it looks like the FW never reaches the point of generating a response for this request. **Our current hypothesis** On the FSS side, we call `Sherpa_Cdd_SetOwnerDebugKeyMap()` once to register the OTP ADKP as the owner authorization/authentication key (`HSE_SRV_ID_DEBUG_KEY_MAPPING`). We suspect this mapping is only being applied in the context of the MU channel that call happens to be dispatched on, and is not visible to the CRS-side HSE2 instance — which would explain why CARD_REQUEST for CRS stalls instead of returning an explicit failure. **Questions** 1. What is the correct debug target / domain ID value for the CRS domain in `AUTH_MODE_REQ` and `CARD_REQUEST`? We are currently assuming `0x1B`; please confirm or correct. 2. Is `Sherpa_Cdd_SetOwnerDebugKeyMap()` (`HSE_SRV_ID_DEBUG_KEY_MAPPING`) required to be issued per-domain/per-MU, or is there a single global mapping shared across FSS and CRS? If per-domain, how is the target MU/owner selected for this service? 3. Does `SetOwnerDebugKeyMap` need to be called on every boot, or is the mapping persistent once set (e.g. tied to OTP/NVM state) so it only needs to be called once? 4. What OID value(s) are expected for the CRS domain in `CARD_REQUEST`? We are currently sending all-`0xFF` (16 bytes), mirroring what works for FSS. 5. What is the expected `CARD_REQUEST` packet structure (`hseDebugCardCmd_t`) for the CRS domain specifically — are there differences from the FSS/APP domain layout in `KRI`, `OID`, `AuthScheme`, or the debug-domain signal map field? 6. How should the Authentication Tag in `CARD_REQUEST` be computed for CRS — is it CMAC over the same `debugCardInfo` fields as for FSS, or does CRS require different fields to be included? Any pointers on the expected sequence/values for the CRS domain would be very helpful — happy to share our CMM script and captured SDC-600 byte log if useful. Thank you. Re: S32N55 HSE2 CRS domain authentication does not complete Hello, @EddiePark
Thanks for your post.
We have initiated discussion with internal teams for your previous 9 questions listed, it is still under investigation, I would reply soon while there are any updates.
For the new questions listed, I will check it first referencing with the previous questions, and then start to investigate on them one by one.
BR
Chenyin
查看全文
