2391427_zh-CN

Yes

S32N55 HSE2 CRS 安全调试：SDC-600 TX FIFO 在传输 20 字节后停止

你好，

关于 CRS 功能域安全调试身份验证问题的后续讨论
之前的帖子中讨论过（“S32N55 HSE2 CRS 功能域身份验证”）
“尚未完成”，我想报告一项新的、更具体的发现。
我认为这指出了问题的根源。单独发布此内容
建议。

设置：
- S32N55、HSE2、CRS 功能域 (APP_CHALLENGE)、劳特巴赫 TRACE32 / SDC-600
- 认证流程：COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE (StartCmd)
-> 接收挑战 -> 发送 ProofProvCmd (debugSignalMap(4B) +
appChallengeAuth(16B) 通过 AES-CMAC)

发现：
发送 debugSignalMap(4B) + appChallengeAuth(16B) = 20 字节后
通过 ProofProvCmd 数据包获取主机 SDC-600 TX FIFO 状态的总数
寄存器（MU 基址 + 0xD2C 处的 bit[7:0]）不再报告可用空间。
换句话说，HSE2 似乎停止消耗 SDC-600 通道的电量。
正好是这 20 字节的边界。主机的底层 Send() 例程
它在一个没有超时的忙等待循环中轮询此状态寄存器，因此
此处无限期封锁。

无论 16 字节之后是什么，这种行为都保持一致。
appChallengeAuth：
- 是否添加额外的填充字节（以填充）
debugAuthProof 联合体（转换为 32 字节）或者不再发送任何内容并继续
直接跳转到 FLAG_END，FIFO 停止在相同的 20 字节处进行数据清空。
观点。这表明问题不在于数据包长度/帧结构。
不匹配，但 HSE2 在以下情况下立即停止为该通道提供服务：
收到 16 字节的 appChallengeAuth。

问题：
这是 APP_CHALLENGE 流程的预期行为吗（例如，HSE2 是否如此）
在此处暂停，等待主机执行其他操作，然后才会继续。
继续排干河道），还是说这表明
到目前为止接收到的数据包内容（debugSignalMap 或
appChallengeAuth）在 HSE2 端被拒绝/格式错误？

供参考：
- FSS 功能域 (FSS_CHALLENGE) 身份验证具有等效流程
使用相同的 Send() 函数成功完成（AUTHSTATUS=0xBBB）。
例行程序和 SDC-600 基座，发送 4B 信号映射 + 32B 响应
没问题。
- CRS 功能域 (APP_CHALLENGE) 目标 = HSE_DEBUG_DOMAIN_APP (0x1B)，
已根据 hse_srv_debug_auth_protocol.h 进行确认。

能否提供一些关于 HSE2 在 APP_CHALLENGE 阶段的期望方面的指导？
非常感谢您的反馈。

谢谢，

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

陈银你好，

感谢您的指导和对剧本的审阅。

我们将等待您就剧本问题提供的详细反馈，并会
一旦修复程序准备就绪，请立即应用。

为了阐明我们目前相对于两阶段方法的立场。
您建议：我们报告的挂起问题（SDC-600 TX FIFO 不再存在）
debugSignalMap + appChallengeAuth) 之后的排水操作恰好发生在
第一阶段结束——具体来说，就是在发送之后。
在能够继续之前，我们需要 hseDebugAuthorizeProofProvCmd_t
hseDebugCardCmd_t 完全不存在。因此，我们尚未确认第一阶段。
端到端执行成功；序列目前停滞在
正是这一点，甚至在达到第二阶段（CardCmd）之前。

收到您的反馈后，我们将：
1. 将修改后的剧本应用到剧本中。
2. 按照分阶段的方法进行重新测试——记录响应
从 hseDebugCommStartCmd_t 到每个命令
单独检查 hseDebugAuthorizeProofProvCmd_t，并确认
在继续进行下一步之前，需要计算每一步的预期值。
3.只有在第一阶段完成后才能继续验证 hseDebugCardCmd_t。
已确认完成。
4. 请汇报更新后的日志。

再次感谢您一直以来的支持。

此致，
埃迪

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

你好， @EddiePark

感谢你的帖子。

1. 我们已经审阅了您分享的原始剧本，发现存在一些问题，我会尽快将反馈意见发送给您。

在审查过程中，我们发现了一些问题，这些问题似乎与已记录的程序不符。因此，我建议仔细比较实际数据包交换与 HSE FW 接口注释中描述的要求。

2. 修复脚本中发现的问题后，进行测试并检查日志。

3. 如果问题仍然存在，我建议将调试过程分为两个阶段，以帮助隔离问题。
首先，验证从 hseDebugCommStartCmd_t 到 hseDebugAuthorizeProofProvCmd_t 的授权序列是否成功完成。记录每个命令的响应，并在进行下一阶段之前确认返回值是否符合预期。

第二阶段，重点关注 hseDebugCardCmd_t。根据 HSE FW 接口文档中提供的评论，我建议严格验证此步骤中涉及的所有数据包，并确认其内容和顺序与文档中规定的要求相符。

BR

陈银

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

你好， @EddiePark

上周我也通过消息发送了它，因为你之前分享的剧本是通过私信发送的。您可以在消息框中查看。

给您带来的不便，敬请谅解。

BR

陈银

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

陈音你好

感谢您之前对 CRS APP 功能域脚本审查的回复。我们衷心感谢您对两阶段调试方法的指导。

由于我们尚未收到您提到的详细剧本反馈（“我会尽快把反馈发给您”），因此我们想跟进并确认一下进度。

为了准备接收您的反馈，我们已经：

1. 我们增强了 crs_auth.cmm 脚本中的日志记录功能，以支持您建议的两阶段方法：
- 第一阶段（CommStart → ProofProv）：添加了逐步响应日志记录，并对每个命令（AUTH_MODE_REQ、APP_CHALLENGE、ProofProv）进行 PASS/FAIL 验证。
- 第二阶段（CardCmd）：准备根据 HSE FW 接口文档验证数据包内容和顺序

2. 准备详细的执行日志，捕获以下内容：
- 每个命令的响应字节
- 生命周期状态解码（OEM_OPEN 与 OEM_CLOSED）
- 身份验证模式确认
- 挑战接收验证
- ProofProv 响应状态（目前观察到 HSE2 在 ProofProv 后保持静默，这与返回 0x4A4A4A4A 的 FSS 功能域不同）

鉴于我方客户（42dot）的交货日期临近，请问您能否就以下方面提供建议：

1. 详细剧本反馈的大概时间是什么时候？
2. 在等待您的反馈期间，我们应该重点关注数据包结构或命令序列的哪些具体方面？

我们仍致力于解决此事，并非常感谢任何进一步的指导。

感谢您一直以来的支持。

此致，

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

你好， @EddiePark

感谢您的回复。

关于您之前的问题：

1. 确认是否需要为APP功能域传输ProofProv？

- 完全不要为 APP 发送 ProofProv（完全跳过 tx_response 调用）？
- 或者发送证明文件但不等待回复（目前尝试过）？

[备注]：第一阶段的ProofProv必须针对 APP 功能域发送。

2. ProofProv 之后脚本卡住的原因可能是什么？（如果仍然需要的话）

[注释]: 在第 1 阶段发送 ProofProv 后，您应该读取 HSE FW 的响应，以检查调试过程是否正常工作（hseDebugAuthorizeProofProvResponse_t）。请确认该回复是否在预期之内。

BR

陈银

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

您好，

平台：S32N55 (HSE2)，通过 SDC600 / TRACE32 CMM 进行安全调试
功能域：APP（CRS）
认证模式：质询（AuthMode = 0）

我正在实现调试卡认证流程。挑战 -> 证明阶段正常工作：在 APP_CHALLENGE 之后，我收到一个 32 字节的挑战并进行计算。

appChallengeAuth = AES256-CMAC(key, challenge) // 16 字节

并将其发送到 hseDebugAuthorizeProofProvCmd_t。

我的问题与 CARD_REQUEST 阶段（hseDebugCardCmd_t / hseDebugCardInfo_t）有关。在我当前的脚本中，AuthTag 字段填充了与上面的 appChallengeAuth 相同的值（即根据接收到的挑战计算出的 CMAC）。信用卡验证失败。

我想确认一下信用卡请求中的 AuthTag 究竟需要签署的是什么：

1. 卡片 AuthTag 是否与 appChallengeAuth（对接收到的质询进行 CMAC 验证）的值相同？

或者

2. AuthTag 是否必须是基于 hseDebugCardInfo_t 结构（在同一请求中发送的卡信息）计算的单独 CMAC？

如果是（2），请您确认一下：
- 进入 CMAC 的确切字节范围（包括整个结构体）。authKeyRef/保留密钥，或特定子集），
- 当 numOfAllowedUids = 0 时，是否包含 uidList，
- 用于 AES-CMAC 的 authScheme 值，以及它是否是签名数据的一部分，
- 序列化结构的打包/字节序假设。

作为参考，我正在填充的结构如下：

typedef struct
{
uint8_t authKeyRef;
uint8_t reserved0[3U];
hseOid_t ownerId; // 16 字节
hseDebugCardAuthScheme_t authScheme;
uint64_t enabledDebugDomainMap; // CRS = 位 22..26 -> 0x0000000007C00000
联盟 {
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;

HSE FW API RM 似乎没有明确说明调试卡 AuthTag 是基于哪些数据计算的，所以我希望得到一个明确的答案。

谢谢！

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

您好，

平台：S32N55 (HSE2)，通过 SDC600 进行安全调试 (APBCOM @ DP:0x5BFF8000)，由 TRACE32 CMM 驱动。

我已经为 FSS 功能域启用了安全调试身份验证（AUTHSTATUS = 0xBBB）。我现在使用完全相同的 SDC600 基本地址和相同的主机端 SEND 例程来启动 APP (CRS) 功能域，但我遇到了传输问题。

观察：
- FSS 功能域：我可以通过 SDC600 传输 32 字节的有效载荷而不会出现任何停顿。
- APP（CRS）功能域：传输在正好 16 个字节后停止。

我的 SEND 例程将每个字节写入 TX 数据寄存器（基址+0xD20），并且在每次写入之前，都会等待 TX 状态寄存器（基址+0xD2C，低字节）的 FIFO 空闲空间：

WHILE (Data.Long(&base+0xD2C) & 0x000000FF) == 0x00000000
（）；等待 TX FIFO 空间

在 APP 功能域中，16 字节后，此状态将无限期地保持为 0（没有可用空间），即 HSE2 端似乎不会在 16 字节之后继续使用 TX FIFO。在 FSS 域上，相同的代码可以无停顿地传输 32 字节。

由于两个功能域的基本地址和 SEND 代码相同，因此这看起来像是 HSE2 何时/是否根据目标调试功能域清空 SDC600 RX（主机 TX）FIFO 存在差异。

问题：
1.什么因素决定了 HSE2 何时开始使用 APP(CRS) 功能域的 SDC600 TX FIFO？是否存在必要的条件/握手（例如）读取 ProofProv 响应、状态位或 RX 使能）必须满足哪些条件，HSE2 才能在 APP 上消耗超过 16 字节？
2. FSS 和 APP 之间 SDC600 流控制/FIFO 消耗行为是否存在功能域差异？
3. 此设备上的 SDC600 TX FIFO 实际深度是多少？0xD2C[7:0] 是否是轮询“TX FIFO 空闲空间”的正确字段？应该使用哪一位？
4. 对于大于 APP 功能域 FIFO 深度的有效载荷，预期的主机发送序列是什么？

其他可能相关的背景信息：
- 在 NOBLOCK 模式下发送 ProofProv (hseDebugAuthorizeProofProvCmd_t) 后，HSE2 确实返回了一个响应，我现在可以将其读取回来 (hseDebugAuthorizeProofProvResponse_t)。我读取到的 4 字节结果是 0x7A 0xB3 0x08 0x00 - 我也希望确认这是否表示 APP 功能域的 ProofProv 成功。

谢谢！