[参考译文] AM263P4：如何将 R5 内核 (HSMclient) 和 HSM 内核 (HSMserver) 之间的 SIPC 交互机制从同步阻断更改为异步通知

您的意思是、我应该循环轮询以下语句：
SIPC_getReadMailbox (&mailboxBaseAddr)；
pendingIntr = SIPC_mailboxGetPendingIntr (mailboxBaseAddr)；
只要 pendingIntr 等于 0、就表示发生了 SIPC 中断并且 HSM 侧已完成处理。 此时、我们可以继续处理 HSM 返回的数据。 但是、我有几个问题：

1、正常的 ISR 流程为 SIPC_ISR →μ s HsmClient_ISR 。 我们现在使用的是 SIPC_mailboxGetPendingIntr 来确定是否发生了 SIPC 中断。 能否确保如果发生 SIPC 中断、也肯定会发生 HsmClient 中断 ？

2、这种方法是否意味着我们不再使用 Semaphorep HSM 内核和 R5 内核之间同步 ？ 如果是、请执行内部的步骤 HsmClient_ISR 引脚声明 ？ 此外、在 Hsmr Client_Send AndRecv 函数中、我应该删除  SemaphoreP_pend  完成后直接退出  SIPC_sendMsg？

3、在查看源代码时,我发现两者都是 SIPC_getReadMailbox 和 SIPC_mailboxGetPendingIntr 是静态 API、无法从外部调用。 如果我想分别提取这两个 API、我是否只需声明相应的全局变量 ？

4、我的理解是正确的、我只需要检查轮询循环中的状态、而诸如清除相应中断标志之类的任务仍应在其中处理 SIPC_ISR？

您好、

1、正常的 ISR 流程是 SIPC_ISR →μ s HsmClient_ISR 。 我们现在使用的是 SIPC_mailboxGetPendingIntr 来确定是否发生了 SIPC 中断。 能否确保如果发生 SIPC 中断、也肯定会发生 HsmClient 中断 ？ [/报价]

HsmClient_ISR 由 SIPC_ISR 调用、如下所示。 它是 SIPC_ISR 的函数调用。 因此、如果出现 SIPC_ISR、那么一定会出现 HSMClient_ISR。

此外、SIPC 仅在 R5 内核和 HSM 内核之间、而不在 R5 内核之间。

2、这种方法是否意味着我们不再使用 Semaphorep HSM 内核和 R5 内核之间同步 ？ 如果是、请执行内部的步骤 HsmClient_ISR 引脚声明 ？ 此外、在 Hsmr Client_Send AndRecv 函数中、我应该删除  SemaphoreP_pend  完成后直接退出  SIPC_sendMsg？ [/报价]

是的、您可以从 HsmClient_isr 中删除 信号量_pend、从 Client_Send AndRecv 中删除信号量_pend、从 HsmClient_isr 中删除信号量_post

查看源代码时、我发现两者都有 SIPC_getReadMailbox 和 SIPC_mailboxGetPendingIntr 是静态 API、无法从外部调用。 如果我想分别提取这两个 API、我是否只需声明相应的全局变量 ？ [/报价]

gSIPC_HsmBoxConfig 和 gSIPC_SecureHostBoxConfig 是固定配置、您可以直接使用它们  

我是正确的、因为我只需要检查轮询循环中的状态、而诸如清除相应中断标志之类的任务仍应在其中处理 SIPC_ISR？ [/报价]

清除中断和处理 SIPC 仍将位于 SIPC_ISR 中。  
来自 HSM 的数据会填充在 HSMClient ISR 中、如下所示  

通常、在我们的大多数服务呼叫中、在调用 Hsm Client_Send AndRecv 后、会对这个收到的响应进行 CRC 检查。 这应该在你结束时予以注意和同步

谢谢。此致、

Nikhil Dasan

[/quote]

[/quote][/quote]

[/quote][/quote][/quote]

① 关于需要修改的特定功能、请验证我的理解是否正确：
SIPC_mailboxGetPendingIntr :因为原始文件直接  在中实现为静态内联  sipc_notify_mailbox.h 、将此标头包括在我的 C 文件中允许在不修改的情况下调用函数。
的修改 SIPC_getReadMailbox ：
备选案文 1. :更改的源代码  SIPC_getReadMailbox  （英寸  SIPC_NOTIFE_src.c ) 到非静态 API、在中声明它  sipc_notify_src.h 、重新编译 SDK 以生成库、然后在我定义的.C 文件中使用它。
选项 2： 直接移动的源代码  SIPC_getReadMailbox  放入我自己的 C 文件中、以及的定义  SIPC_ctrl 和声明  gSIPC_ctrl  如下图所示。

您推荐哪种方法？ 我们认为、尽可能避免修改 SDK 源代码通常会更好。

HsmClient_ISR 函数： 您提到了屏蔽 SEMAPHOREP_POST 、因为不再需要此信标。 是否可以保持不变？ 同样、我们倾向于尽可能避免修改 SDK 源代码。 当然、 SemaphoreP_Pend 将在 Client_Send AndRecv 中删除。

②  Hsm Client_Send AndRecv、 收到信标后、依次执行以下操作：
crc16_ccit ((uint8_t *)&HsmClient->RespMsg、SIPC_MSG_SIZE - 2)；
和
crc16_ccit ((uint8_t *) HsmClient->RespMsg.args、sizeof (HsmAES_t))；
（包括  SoC_phyToVirt  和  CacheP_inv )。

现在、通过切换到异步通信、我将首先执行  SIPC_sendMsg  指定  Hsm Client_Send AndRecv  并立即返回。 那么、在轮询期间、何时  SIPC_mailboxGetPendingIntr  返回 0、我需要按顺序执行 CRC 检查  HsmClient->RespMsg  和  HsmClient->RespMsg.args 。 这是正确的过程吗？

仿真 R5 内核和 HSM 内核的程序加载（启用 M4 的调试权限、通过.out 文件加载、HSM 函数正常运行）。

阶段 1：R5 内核向 HSM 内核发送 SIPC（写入邮箱）、从而触发 HSM 内核的 SIPC 中断。 但是、HSM 内核的 SIPC 中断不会继续进行。 此时、读取 SIPC_mailboxGetPendingIntr (mailboxBaseAddr) 将返回 0。

阶段 2：R5 内核卡在 SemaphoreP_pend 处、等待 SemaphoreP_POST 。

阶段 3：触发 HSM 内核的 SIPC 中断后、  调用 HsmServer_ISR、后跟相应的处理程序。 然后、HSM 内核向 R5 内核发送 SIPC（写入邮箱）、从而触发 R5 内核的 SIPC 中断。 处理 SIPC 中断后、 SemaphoreP_Pend 可以继续。 在此阶段、读取 SIPC_mailboxGetPendingIntr (mailboxBaseAddr) 将返回 0。

我的问题是：  SIPC_mailboxGetPendingIntr 是否应该在阶段 1 中返回非零值？ 因为此时尚未触发 R5 内核的 SIPC 中断（HSM 尚未向 R5 内核发送 SIPC（邮箱写入）)。

或者、我是否使用不当？ 所描述的代码仅用于测试目的。

感谢您的答复。 这个问题很紧迫

您好、

您可以检查 API Hsm.AndSendMsg()、而不是 HSM_Sendandrecv、它是一个非阻塞 Client_Enqueue 发送 API、用于 proc 验证启动、更新和停止 API。  

您对 API 的更新应该与这一个类似。

谢谢。此致、

Nikhil Dasan

1、你提到我应该更换 Hsm Client_Send AndRecv 一方 Hsm Client_Enqueue AndSendMsg 发送 SIPC 消息。 但是、我注意到这也是一个静态 API。 我应该直接将其代码复制到 C 文件中 ？

2、请您看看这个问题 ？ 其中、 SIPC_getReadMailbox 使用方法 2 实现（直接将 SIPC_getReadMailbox 的源代码移动到我自己的 C 文件中、包括 SIPC_ctrl 的定义并声明 gSIPC_ctrl，如图所示）。

3、也请查看有关的修改问题 HsmClient_ISR 测量输出。

我的问题是：  SIPC_mailboxGetPendingIntr 是否应该在阶段 1 中返回非零值？ 因为此时尚未触发 R5 内核的 SIPC 中断（HSM 尚未向 R5 内核发送 SIPC（邮箱写入）)

在这种情况下、第一个挂起中断将位于 HSM 的 mailboxBaseAddr 上、因为 R5F 已触发中断。 仅当 HSM 触发邮箱中断时、挂起才会在 R5 端为非零

3、有关的修改、请同时查看此问题 HsmClient_ISR 功能。

不建议和测试不带挂起的 POST。 如前所述、除了 mcelf 映像的 proc_auth_boot 服务外、HSMClient API 针对分块用例进行了测试。  

只有此服务使用非阻塞方法、因为情况需要相同。

请问您在取消阻止 HSM 服务中要寻找什么用例？

谢谢。此致、

Nikhil Dasan

让我重新表述我的理解。

相位 1：在 R5 内核执行 SIPC_mailboxWrite 后、它会在 HSM 内核上触发 SIPC 中断。 此时、HSM 内核进入 SIPC_ISR。 在 SIPC_ISR 中、它首先执行 SIPC_mailboxGetPendingIntr。 此时从 HSM_SOC_CTRL_HSM_MBOX_READ_DONE 寄存器读取的值为 0x00000001、表示 HSM 内核侧存在挂起中断。 然后、它执行 SIPC_mailboxClearPendingIntr 来清除 HSM_SOC_CTRL_HSM_MBOX_READ_DONE 寄存器、将其值设置为 0x00000000。

第 2 阶段：HSM 内核执行相应的操作（例如 TRNG、AES、RSA）、然后执行 SIPC_mailboxWrite、这会在 R5 内核上触发 SIPC 中断。

第 3 阶段：此时、R5 内核进入 SIPC_ISR。 在 SIPC_ISR 中、它首先执行 SIPC_mailboxGetPendingIntr。 此时从 MSS_CTRL_R5SS0_CORE0_MBOX_READ_DONE 寄存器读取的值为 0x01000000、表示 R5 内核侧存在挂起的中断。 然后、它执行 SIPC_mailboxClearPendingIntr 以清除 MSS_CTRL_R5SS0_CORE0_MBOX_READ_DONE 寄存器、将其值设置为 0x00000000。

①Is 我的理解正确吗？

现在、回到前面关于如何确定 HSM 内核是否已完成相应操作以实现异步操作的问题、您之前的建议是使用 SIPC_mailboxGetPendingIntr 来查询 R5 内核触发 HSM 内核上的 SIPC 中断后是否存在挂起的中断。

理想情况下、在 R5 内核触发 HSM 内核上的中断且 HSM 内核完成其任务后、会在 R5 内核上触发 SIPC 中断。 在 R5 内核的中断服务例程中、挂起的中断被同步清除（通过将 MSS_CTRL_R5SS0_CORE0_MBOX_READ_DONE 寄存器归零）。 因此、只要 SIPC_mailboxGetPendingIntr 返回 0、就表示 HSM 内核已完成其操作。

但我有一个问题：在 R5 内核触发 HSM 内核上的 SIPC 中断后、虽然 HSM 内核仍在处理此任务、但尚未在 R5 内核上触发 SIPC 中断。 在此场景中、仿真显示执行 SIPC_mailboxGetPendingIntr 也会返回 0。

② μ s 我如何区分 HSM 内核已完成任务并触发 R5 内核中断的情况和 HSM 内核仍在处理任务的情况？

您好、

很抱歉、由于假期、回复延迟。

[报价 userid=“655954" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1599916/am263p4-how-to-change-the-sipc-interaction-mechanism-between-the-r5-core-hsmclient-and-the-hsm-core-hsmserver-from-synchronous-blocking-to-asynchronous-notification/6170674

相位 1：在 R5 内核执行 SIPC_mailboxWrite 后、它会在 HSM 内核上触发 SIPC 中断。 此时、HSM 内核进入 SIPC_ISR。 在 SIPC_ISR 中、它首先执行 SIPC_mailboxGetPendingIntr。 此时从 HSM_SOC_CTRL_HSM_MBOX_READ_DONE 寄存器读取的值为 0x00000001、表示 HSM 内核侧存在挂起中断。 然后、它执行 SIPC_mailboxClearPendingIntr 来清除 HSM_SOC_CTRL_HSM_MBOX_READ_DONE 寄存器、将其值设置为 0x00000000。

第 2 阶段：HSM 内核执行相应的操作（例如 TRNG、AES、RSA）、然后执行 SIPC_mailboxWrite、这会在 R5 内核上触发 SIPC 中断。

第 3 阶段：此时、R5 内核进入 SIPC_ISR。 在 SIPC_ISR 中、它首先执行 SIPC_mailboxGetPendingIntr。 此时从 MSS_CTRL_R5SS0_CORE0_MBOX_READ_DONE 寄存器读取的值为 0x01000000、表示 R5 内核侧存在挂起的中断。 然后、它执行 SIPC_mailboxClearPendingIntr 以清除 MSS_CTRL_R5SS0_CORE0_MBOX_READ_DONE 寄存器、将其值设置为 0x00000000。

①Is 我的理解正确吗？

[/报价]

是的、正确。

[报价 userid=“655954" url="“ url="~“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1599916/am263p4-how-to-change-the-sipc-interaction-mechanism-between-the-r5-core-hsmclient-and-the-hsm-core-hsmserver-from-synchronous-blocking-to-asynchronous-notification/6170674

但我有一个问题：在 R5 内核触发 HSM 内核上的 SIPC 中断后、虽然 HSM 内核仍在处理此任务、但尚未在 R5 内核上触发 SIPC 中断。 在此场景中、仿真显示执行 SIPC_mailboxGetPendingIntr 也会返回 0。

② μ s 我如何区分 HSM 内核已完成任务并触发 R5 内核中断的情况和 HSM 内核仍在处理任务的情况？

[/报价]

如上所述、在 R5 内核触发向 HSM 内核发送 SIPC 中断后、挂起的应该是 从 SIPC_mailboxGetPendingIntr 获取 0x01000000。

收到此消息后、我们便知道 HSM 已完成其操作、然后应通过 R5F 内核清除。

请问您在解锁 HSM 服务中要用什么用例？

我再问一次。 我想知道应该取消阻止 HSM 服务的用例。

谢谢。此致、

Nikhil Dasan

感谢您的答复。

根据您的说明、在 R5 内核触发 HSM 内核的 SIPC 中断之后、在 HSM 内核触发对 R5 内核的 SIPC 中断之前、我读取的值  SIPC_mailboxGetPendingIntr  不应为零。 但是、在仿真测试期间、i Read 的值仍然为 0。 我想问为什么会发生这种情况？

为了进行澄清、我正在仿真 HSM 程序的.out 文件、在 R5 内核触发 HSM 内核的 SIPC 中断后、我特意在下面的 ISR 中暂停、以防止 HSM 内核触发将 SIPC 中断返回到 R5 内核。

我  在接下来的时间点（在 R5 内核触发 HSM 内核的 SIPC 中断之后）放置了 SIPC_mailboxGetPendingIntr 调用来读取该值。

关于您的问题、由于我们现在计划在 AUTOSAR 架构下统一 HSM 服务请求、因此所有 HSM 服务（如 TRNG、AES、SHA、RSA 和 ECC）都必须支持异步和同步运行模式。 因此、我们必须放弃以前使用 SemaphoreP post/pend 的方法来确定 HSM 内核是否已完成任务、并改为切换到中断标志指示器等方法。

您好、

根据您的说明、在 R5 内核触发对 HSM 内核的 SIPC 中断之后、在 HSM 内核触发对 R5 内核的 SIPC 中断之前、我读取的值  SIPC_mailboxGetPendingIntr  不应为零。 但是、在仿真测试期间、i Read 的值仍然为 0。 我可以问为什么会发生这种情况吗？

否、 只有在 HSM 内核触发到 R5 的 SIPC 中断之后、SIPC_mailboxGetPendingIntr 的值才会为 0x01000000、并将其保留该值、直到您将其清除为止。

关于您的问题、由于我们现在计划统一 AUTOSAR 架构下的 HSM 服务请求、因此所有 HSM 服务（如 TRNG、AES、SHA、RSA 和 ECC）都必须支持异步和同步运行模式。 因此、我们必须放弃以前使用 SemaphoreP post/pend 的方法来确定 HSM 内核是否已完成任务、并改为切换到中断标志指示器等方法。

我明白了。 感谢您对此进行澄清。

是的、我的理解实际上与您的理解相同。

简要描述整个任务执行流程：
① R5 内核向 HSM 内核触发 SIPC 中断 (PendingIntr = 0x00000001)。
② HSM 内核清除中断 (PendingIntr = 0)、然后处理任务。
③ 任务完成后、HSM 内核会向 R5 内核触发 SIPC 中断 (PendingIntr = 0x01000000)。
④ R5 内核清除中断 (PendingIntr = 0)、接收信息并完成整个任务。

   我的初衷是 请 ② TI 提供一种方法、在我执行阶段 ① 后、我可以确定系统是处于阶段 ③（HSM 内核正在处理）还是阶段（HSM 内核已完成处理）。

   然而、正如我在上文所述、在 ② 阶段期间、SIPC_mailboxGetPendingIntr 显示 PendingIntr = 0。 在阶段 ③ 中、尽管 SIPC_mailboxGetPendingIntr 非常短暂地将 PendingIntr 读取为 0x01000000、但 ISR 会很快将其清除并再次变为 0。 因此、如果我不断调用 SIPC_mailboxGetPendingIntr 来读取 PendingIntr（以获得 HSM 执行状态）、我可以认为读取 PendingIntr 始终为 0（除非它是 0x01000000 时非常短暂的时刻）。

   根据这个逻辑、我个人认为、仅使用 SIPC_mailboxGetPendingIntr 不足以确定 HSM 内核是正在处理（阶段 ②）还是已完成处理（阶段 ③）。 因此、您能否提供一种实用可靠的方法来实现上述功能？

   我之前考虑了直接在 R5 内核的 SIPC ISR 中添加一个自定义标志、然后判断该标志的状态以确定 HSM 内核是否触发到 R5 内核的 SIPC 中断、从而从根本上确定 HSM 内核是否已完成其任务。 但是、我希望在确保程序可靠性的同时尽可能避免修改原始 SDK 代码。

您好、

很抱歉耽误响应。  

如果不修改驱动程序、我们无法实现这一点。

实现这一点的最简单方法是在 Hsmclient_ISR 中调用回调函数、它将是应用程序中的一个函数（而不是发布信标）、

这样您就可以获得应用级 HSM 响应接收情况的信息。

这将是实现这一目标的更清洁的方法。

谢谢。此致、

Nikhil Dasan

大家好、我们还有另一种方法：

相关  SemaphoreP_pend  即  的超时参数  SemaphoreP_pend  设置为的频率  SystemP_WAIT_FOREVER 。 这意味着一次  SemaphoreP_pend  被调用时、它会持续轮询信标、直到它被释放、这构成了同步示例中 HSMClient 的基础。 我现在正在考虑将 超时更 改为  SystemP_NO_WAIT 。 而不是无限期地等待  SemaphoreP_pend 、该功能只会检查一次。 如果未释放信标、它将退出该函数并继续执行其他任务、直到下一个轮询周期完成  SemaphoreP_pend  频率。 如果释放信标、则会读取 HSM 返回的数据。 该方法旨在实现类似异步的通信。 该方法是否适用于在没有操作系统的应用程序中实现异步通信？

以下是经过验证可在实践中使用的特定工作流程：

① 发起 HSM 客户端请求、例如 AES 操作。

② 在轮询循环中、检查信标 SemaphoreP 是否 已释放。

③ 在轮询循环中、如果 jobProcessState == Job_Process_State_finish 在步骤 ② 中、则调用  HsmClient_AES_HsmClient_ Algo_Callback  以便处理 HSM 返回的数据。

具体如下  Hsm Client_Send  和  Hsm Client_Recv 、它们通过拆分原件而派生  Hsm Client_Send AndRecv  API。

感谢您的回复！！

当然、  

关于此处的信标实现、您是否在信标 API 中使用自己的实现？ 因为在 SDK 版本中、此实现有一个 nortos / FreeRTOS 版本。

假设你有 autosar 运行,你会有同一个权利的 autosar 版本?

谢谢。此致、

Nikhil Dasan

您好、感谢您的答复

前面提到的 SemaphoreP_Pend 仍然基于 SDK、但示例代码中的 timeToWaitInTicks 参数已从 SystemP_WAIT_FOREVER 更改为 SystemP_NO_WAIT。 这使得该过程能够避免在未通过 POST 操作立即释放信标时无限期阻止。 相反,它可以继续处理其他任务并稍后检查 SemaphoreP 状态,实现类似于异步通信的效果。 这种方法是我能想到的在现有程序内实现异步通信的最小修改。

上述测试验证是在无操作系统应用中进行的。 ：、在使用操作系统的应用程序中进行测试时会出现问题、如引用的 POSTAM263P4 所述：根据 Pre-release MCAL 11.01.00.07 中的 FLS_BOOT_APP 示例、无法多次检索 TRNG、这就是问题。 -基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛

根据您的说明、noRTOS 和 FreeRTOS 等信标的实现（如 SemaphoreP_pend）是否不同？ 我们使用的操作系统是 OSEK。 我是否可以询问 TI 基于 FreeRTOS 实现的信标 API 也可以在基于 OSEK 的系统上运行？

您好、

很抱歉耽误响应。

是的、根据所用的操作系统、DPL 层的实现存在差异。 即 nortos 与 FreeRTOS 之间存在差异、因为我们在 FreeRTOS OS 中使用 FreeRTOS API。

Semaphorep 是一个 DPL API。
添加了设备移植层 (DPL)、也称为操作系统抽象层、以抽象处理特定于操作系统的 API。

OSEK 是 Autosar、因此这将有另一种实现方式  

对于 nortos、需要超时计时器、而在 FreeRTOS RTOS 中、计时器可以处理超时、我相信 OSEK 也是如此。  

谢谢。此致、

Nikhil Dasan