S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hello, Following up on the CRS domain Secure Debug authentication issue discussed in the earlier post ("S32N55 HSE2 CRS domain authentication does not complete"), I'd like to report a new, more specific finding that I believe points to the root cause. Posting this separately as suggested. Setup: - S32N55, HSE2, CRS domain (APP_CHALLENGE), Lauterbach TRACE32 / SDC-600 - Auth flow: COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE (StartCmd) -> receive challenge -> send ProofProvCmd (debugSignalMap(4B) + appChallengeAuth(16B) via AES-CMAC) Finding: After sending debugSignalMap(4B) + appChallengeAuth(16B) = 20 bytes total via the ProofProvCmd packet, the host's SDC-600 TX FIFO status register (bit[7:0] at MU base+0xD2C) never reports free space again. In other words, HSE2 appears to stop draining the SDC-600 channel at exactly this 20-byte boundary. The host's low-level Send() routine polls this status register in a busy-wait loop with no timeout, so it blocks indefinitely at this point. This behavior is consistent regardless of what follows the 16-byte appChallengeAuth: - Whether we append additional padding bytes (to fill out the debugAuthProof union to 32 bytes) or send nothing further and go straight to FLAG_END, the FIFO stops draining at the same 20-byte point. This suggests the issue is not a packet-length/framing mismatch, but that HSE2 stops servicing the channel right after receiving the 16-byte appChallengeAuth. Question: Is this expected behavior for the APP_CHALLENGE flow (e.g., does HSE2 pause here awaiting some other action from the host before it will continue draining the channel), or does this indicate that the packet content received up to this point (debugSignalMap or appChallengeAuth) was rejected/malformed on the HSE2 side? For reference: - FSS domain (FSS_CHALLENGE) authentication with the equivalent flow completes successfully (AUTHSTATUS=0xBBB) using the same Send() routine and SDC-600 base, sending 4B signal map + 32B response with no issue. - CRS domain (APP_CHALLENGE) target = HSE_DEBUG_DOMAIN_APP (0x1B), confirmed against hse_srv_debug_auth_protocol.h. Any guidance on what HSE2 expects at this point in the APP_CHALLENGE flow would be greatly appreciated. Thanks, Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hi Chenyin, Thank you for the guidance and for reviewing the script. We'll wait for your detailed feedback on the script issues and will apply the fixes as soon as it's ready. To clarify where we currently stand relative to the two-phase approach you suggested: the hang we reported (SDC-600 TX FIFO no longer draining after debugSignalMap + appChallengeAuth) occurs right at the end of Phase 1 — specifically right after sending hseDebugAuthorizeProofProvCmd_t, before we are able to proceed to hseDebugCardCmd_t at all. So we have not yet confirmed that Phase 1 completes successfully end-to-end; the sequence currently stalls at this exact point, before Phase 2 (CardCmd) is even reached. Once we receive your feedback, we will: 1. Apply the corrections to the script. 2. Re-test following your phased approach — logging the response of each command from hseDebugCommStartCmd_t through hseDebugAuthorizeProofProvCmd_t individually, and confirming expected values at each step before proceeding further. 3. Only move on to validating hseDebugCardCmd_t once Phase 1 is confirmed to complete successfully. 4. Report back with the updated logs. Thanks again for your continued support. Best regards, Eddie Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hello, @EddiePark
Thanks for your post.
1. We have reviewed the original script shared, and found that there are some issues, I will send you the feedback soon.
During the review, we identified some issues that do not seem to align with the documented procedure. Therefore, I would recommend carefully comparing the actual packet exchange with the requirements described in the comments of HSE FW Interface.
2. Once fixed the issues found in the script, test and check the log.
3. If still issues, I would recommend breaking the debugging procedure into two phases to help isolate the issue. As a first step, verify that the authorization sequence from hseDebugCommStartCmd_t through hseDebugAuthorizeProofProvCmd_t completes successfully. And log the response of each command and confirm that the returned values are as expected before proceeding to the next stage.
In the second stage, focus on hseDebugCardCmd_t. Based on the comments provided in the HSE FW Interface documentation, I would suggest strictly validating all packets involved in this step and confirming that their contents and sequence match the documented requirements.
BR
Chenyin
Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hello, @EddiePark
I've also sent it last week via the messages since the previous script you shared is via the private message. You may check it there in your message box.
Sorry for any inconvenience.
BR
Chenyin Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hello Chenyin, Thank you for your previous response regarding the CRS APP domain script review. We sincerely appreciate your guidance on the two-phase debugging approach. Since we have not yet received the detailed script feedback you mentioned ("I will send you the feedback soon"), we wanted to follow up and check on the status. To prepare for your feedback, we have already: 1. Enhanced logging in our crs_auth.cmm script to support the two-phase approach you recommended: - Phase 1 (CommStart → ProofProv): Added step-by-step response logging with PASS/FAIL validation for each command (AUTH_MODE_REQ, APP_CHALLENGE, ProofProv) - Phase 2 (CardCmd): Ready to validate packet contents and sequence per HSE FW Interface documentation 2. Prepared detailed execution logs capturing: - Each command's response bytes - Lifecycle state decoding (OEM_OPEN vs OEM_CLOSED) - Authentication mode confirmation - Challenge reception validation - ProofProv response status (currently observing HSE2 remains silent after ProofProv, unlike FSS domain which returns 0x4A4A4A4A) Given that our customer (42dot) delivery schedule is approaching, could you please advise on: 1. Approximate timing for the detailed script feedback? 2. Are there any specific aspects of the packet structure or command sequence we should focus on while awaiting your feedback? We remain committed to resolving this and would greatly appreciate any additional guidance. Thank you for your continued support. Best regards, Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hi, Platform: S32N55 (HSE2), Secure Debug via SDC600 / TRACE32 CMM Domain: APP (CRS) Auth mode: Challenge (AuthMode = 0) I am implementing the debug card authentication flow. The challenge -> ProofProv phase works: after APP_CHALLENGE I receive a 32-byte challenge and compute appChallengeAuth = AES256-CMAC(key, challenge) // 16 bytes and send it in hseDebugAuthorizeProofProvCmd_t. My question is about the CARD_REQUEST phase (hseDebugCardCmd_t / hseDebugCardInfo_t). In my current script the AuthTag field is filled with the SAME value as appChallengeAuth above (i.e. the CMAC computed over the received challenge). The card authentication is rejected. I would like to confirm what the AuthTag in the card request must actually be signed over: 1. Is the card AuthTag simply the same value as appChallengeAuth (CMAC over the received challenge)? OR 2. Must the AuthTag be a separate CMAC computed over the hseDebugCardInfo_t structure (the card info being sent in the same request)? If it is (2), could you please confirm: - the exact byte range that goes into the CMAC (whole struct incl. authKeyRef/reserved, or a specific subset), - whether uidList is included when numOfAllowedUids = 0, - the authScheme value to use for AES-CMAC and whether it is part of the signed data, - packing / endianness assumptions for the serialized struct. For reference, the structure I am populating: typedef struct { uint8_t authKeyRef; uint8_t reserved0[3U]; hseOid_t ownerId; // 16 bytes hseDebugCardAuthScheme_t authScheme; uint64_t enabledDebugDomainMap; // CRS = bits 22..26 -> 0x0000000007C00000 union { hseDebugSignal_t debugDomainSignalList[HSE_MAX_NUM_OF_DEBUG_DOMAINS]; uint8_t reserved1[64U]; } debugDomainSignalList; uint8_t numOfAllowedUids; uint8_t reserved2[3U]; uint8_t uidList[HSE_MAX_UID_LIST_SIZE][HSE_UID_SIZE]; } hseDebugCardInfo_t; The HSE FW API RM does not seem to state explicitly which data the debug card AuthTag is computed over, so I would appreciate a definitive answer. Thank you. Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hello, @EddiePark
Thanks for your reply.
Regarding to your previous questions:
1. Confirm whether ProofProv should be transmitted for APP domain?
- Do NOT send ProofProv at all for APP (skip the tx_response call entirely)? - or Send ProofProv but don't wait for response (currently attempted)?
[Comments]: The ProofProv in phase 1 must be sent for APP domain.
2. What may be causing the script stall after ProofProv? (If it is still needed)
[Comments]: After sending the ProofProv in phase 1, you should read the response from HSE FW to check if debug process worked fine(hseDebugAuthorizeProofProvResponse_t). Please check if the response is expected.
BR
Chenyin Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes Hi, Platform: S32N55 (HSE2), Secure Debug over SDC600 (APBCOM @ DP:0x5BFF8000), driven from TRACE32 CMM. I have Secure Debug authentication working for the FSS domain (AUTHSTATUS = 0xBBB). I am now bringing up the APP (CRS) domain using the exact same SDC600 base address and the same host-side SEND routine, but I hit a transmit problem. Observation: - FSS domain: I can transmit a 32-byte payload through SDC600 without any stall. - APP (CRS) domain: transmission stalls after exactly 16 bytes. My SEND routine writes each byte to the TX data register (base+0xD20) and, before each write, waits on the TX status register (base+0xD2C, lower byte) for FIFO free space: WHILE (Data.Long(&base+0xD2C) & 0x000000FF) == 0x00000000 ( ) ; wait for TX FIFO space On the APP domain, after 16 bytes this status stays 0 (no free space) indefinitely, i.e. the HSE2 side does not appear to consume the TX FIFO beyond 16 bytes. On the FSS domain the same code streams 32 bytes without stalling. Because the base address and SEND code are identical for both domains, this looks like a difference in when/whether HSE2 drains the SDC600 RX (host TX) FIFO depending on the target debug domain. Questions: 1. What determines when HSE2 begins consuming the SDC600 TX FIFO for the APP(CRS) domain? Is there a required condition/handshake (e.g. reading back the ProofProv response, a status bit, or an RX-enable) that must be satisfied before HSE2 will drain more than 16 bytes on APP? 2. Is there a per-domain difference in the SDC600 flow-control / FIFO consumption behavior between FSS and APP? 3. What is the actual SDC600 TX FIFO depth on this device, and is 0xD2C[7:0] the correct field to poll for "TX FIFO free space"? Which exact bit should be used? 4. For a payload larger than the FIFO depth on the APP domain, what is the intended host transmit sequence? Additional context that may be relevant: - After sending ProofProv (hseDebugAuthorizeProofProvCmd_t) in NOBLOCK mode, HSE2 does return a response and I can now read it back (hseDebugAuthorizeProofProvResponse_t). The 4-byte result I read is 0x7A 0xB3 0x08 0x00 - I would also appreciate confirmation of whether this indicates ProofProv success for the APP domain. Thank you.
View full article
