Hi,
Following up on S32N55 (HSE2) Secure Debug. CRS(APP) challenge-response authentication now works (final response 0x4A4A4A4A). I am now on the debug card request (HSE_DEBUG_CMD_CARD_REQUEST), and it returns:
HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR ((hseDebugError_t)0x20) — "invalid debug domain map in debug card."
What I send (per your earlier feedback):
Packet2 Debug Domain Signal List: array style, List[22..26] = 0x01 each (CRS: Cortex-M7, PCIe, CRS NoC/CAN NoC, CANXL0-1, CANXL2-3), all other bytes 0x00.
Packet3 enabledDebugDomainMap (uint64_t): 0x07C00000 as advised (bits 22-26).
AuthScheme: macAlgo = HSE_MAC_ALGO_CMAC = 0x11.
AuthTag: AES256-CMAC over the card info, authLen = 16.
What I have tried for enabledDebugDomainMap (uint64_t, 8 bytes on the wire):
Little-endian: 00 00 C0 07 00 00 00 00 → 0x20
Big-endian: 00 00 00 00 07 C0 00 00 → 0x20
bit27 (0x08000000, matching AUTH target 0x1B) → 0x20
All return the same 0x20.
Questions:
1. For CRS, what is the exact enabledDebugDomainMap (uint64_t) value HSE expects, and in what wire byte order?
2. Must enabledDebugDomainMap (Packet3 bitmask) be consistent with the Debug Domain Signal List (Packet2, array List[22..26])? What is the exact relationship?
3. The RM example states "domain 1,3 enabled → 0x00..A0." Could you clarify the domain-to-bit mapping so I can compute the CRS value?
4. Does HSE validate the domain map before verifying the AuthTag? I want to confirm whether 0x20 indicates only the domain map is wrong, or whether other fields (e.g. the AuthTag / signed data range) could also be causing HSE to stop at this point.
I also want to confirm the signed data range for the card AuthTag: I currently compute AES256-CMAC over the card info fields (authKeyRef + reserved0 + ownerId + authScheme + signal list + domain map + UID list). Is this the correct data to sign?
Best regards,
