[参考译文] AM2432：对 OTP 进行编程后、不会接收到 TISCI_MSG_FLAG_ACK 标志

您好！

请分享 Keywriter 启动日志以分析问题的原因。 如果出现故障、日志中将有一个错误代码、用于分析故障。

此致、

Prashant

您好 Prashant：  

我们无法访问 UART1日志。 我们是否有其他方法可以调试该问题？  是否可以将输出从 UART1引导至 UART0？  

Hong

Unknown 说：

如果出现故障、日志中将显示一个错误代码、用于分析故障。

这些日志来自仅 UART0上提供的 SBL。

日志如下所示

Starting Keywriting
Enabled VPP
keys Certificate found: 0x70042b00
Keywriter Debug Response:0x0
Success Programming Keys

您好 Prashant：

UART0未报告本例的错误代码。  

 DebugP_assertNoLog ((STATUS == SystemP_SUCCESS)&&((respParam.flags & TISCI_MSG_FLAG_ACK)== TISCI_MSG_FLAG_ACK))；failed 是在之后  

成功编程密钥  

都会打印出来。  

Hong  

您好！

请应用以下补丁在 UART0控制台上打印 SYSFW 日志

diff --git a/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/keywriter_utils.c b/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/keywriter_utils.c
index c48be90f..cc875f39 100644
--- a/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/keywriter_utils.c
+++ b/source/security/sbl_keywriter/am243x-evm/r5fss0-0_nortos/keywriter_utils.c
@@ -226,6 +226,21 @@ void keywriter_setBoardCfg(void)
 	}
 }
 
+void dump_sysfw_logs()
+{
+    uint8_t* ptr = (uint8_t*)0x44043000;
+
+    DebugP_log("\r\n<<SYSFW_LOGS\r\n");
+
+    for(int32_t i = 0; i < 0x0FE0; i++)
+    {
+        DebugP_log("%c", *ptr);
+        ptr++;
+    }
+
+    DebugP_log("\r\nSYSFW_LOGS\r\n");
+}
+
 void keywriter_processKeyConfig(void)
 {
     int32_t status = SystemP_SUCCESS;
@@ -254,6 +269,8 @@ void keywriter_processKeyConfig(void)
 
 	DebugP_log("Keywriter Debug Response:0x%x \r\n", (uint32_t) response.debug_response);
 
+    dump_sysfw_logs();
+
 	if (( status == SystemP_SUCCESS ) && ( response.debug_response == 0x0U ))
 	{
 		DebugP_log("Success Programming Keys \r\n");

此致、

Prashant

非常感谢、Prashant。

这肯定会对我们的调试有所帮助。  

Hong  

您好 Prashant：  

我仍在努力重现这个问题。  

同时、您能否帮助了解当我们在日志中有成功编程密钥时、此处可能会出现什么问题、  

但在接下来的这个步骤中失败了。  
DebugP_assertNoLog ((STATUS == SystemP_SUCCESS)&&((respParam.flags & TISCI_MSG_FLAG_ACK)== TISCI_MSG_FLAG_ACK))；   


当 未以标志接收到 TISCI_MSG_FLAG_ACK 时、对 Keywriter 会有什么影响？ 这是否意味着之前的编程失败？ 这与"成功编程密钥"存在某种冲突。   

谢谢！  
Hong  

您好！

理想情况下、 如果 Keywriter 在日志中报告"Success Programming Keys"、则标志应具有 TISCI_MSG_FLAG_ACK。

Unknown 说：

同时、如果我们在日志中有成功编程密钥、您能帮助了解此处可能出现的问题吗

评估这种情况可能发生的条件(如果可能的话)是不可行的。  如果您可以重现问题并提供 SYSFW 日志、则我们可以分析故障。

除此之外、我可否知道以下情况？

• 您正在使用的 SDK 版本和 Keywriter 版本？
• 检查 Keywriter 的执行状态的原因是什么？ 通常、如果我看到 Keywriter 报告"Success Programming Keys (成功编程密钥)"、我会假设一切正常。

此致、

Prashant

您好 Prashant：  

感谢您的答复。  

我尝试添加 SYSFW 日志来调试此问题并 看到 其他一些问题。

我在使用添加的 SYSFW 日志打印对外部 OTP 数据进行编程时看到了此故障、并且也无法转储外部 OTP 数据、请查看有关外部 OTP 数据转储问题的详细信息的电子邮件。  

对密钥编程失败、状态= 0、response.debug_response = 0x20000000

对于另外两个问题、  

• 您正在使用的 SDK 版本和 Keywriter 版本？
  
  Keywriter 基于 SDK 9.1版本。  Keywriter 二进制是使用 SDK 9.1编译的。  
  
  
• 检查 Keywriter 的执行状态的原因是什么？ 通常、如果我看到 Keywriter 报告"Success Programming Keys (成功编程密钥)"、我会假设一切正常。
  
  我们间接发现了这个问题、因为我们在  TISCI_MSG_FLAG_ACK 有效之后添加了一个打印输出 来打印一些其他调试信息、我发现该行出现错误、调试信息没有打印出来。 我们还添加了禁用 VPP 的功能、该功能也未被执行。  
  

非常感谢、  
Hong  

您好、Hong：

Unknown 说：

编程密钥失败、状态= 0、response.debug_response = 0x20000000

请共享 SYSFW 日志。

Unknown 说：

并且无法转储外部 OTP 数据

无法直接读取 EXT OTP MMR。 SYSFW 为 EXT OTP 提供 API：

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/extended_otp.html

对于 Keywriter、您无需读回任何内容。 SYSFW 日志具有验证 OTP 编程所需的任何内容。

此致、

Prashant

您好 Prashant：  

感谢您的答复。   

我能够在 Keywriter 工程中添加 SYSFW 日志打印功能、具有一个字节的较小 EXT OTP 大小。  

 对于较大的 EXT OTP 大小、response.debug_response = 0x20000000可能还具有一些其他问题。 鉴于这不是我们的用例、而只是测试用例、我想重新强调一下 未收到 TISCI_MSG_FLAG_ACK 的问题、正如我先前在运行 Keywriter 对 OTP 密钥进行编程时所指出的。  

我们将尝试在打印 SYSFW 日志的情况下重现问题、并将通过电子邮件发送此问题。  

谢谢！  
Hong  

感谢您的更新、Hong。

我将等待您对原始问题再现性的反馈。

Prashant、您好！

谢谢！ 我向您发送了一封包含最新状态/咨询的电子邮件。  最重要的是没有收到 Ack、我们需要了解其原因。  然后、我们需要 修复/更新/更改、以便始终可靠地接收 ACK。

谢谢、Merril

您好！

正如我刚才所说、评估问题发生的条件是不可行的。 这可能是错误的观察。 这是首次报告此类问题。

客户是否验证 print 语句没有执行、因为执行卡在 DebugP_assertNoLog 语句中、还是只是推测？

如果客户获得了"成功编程密钥"、他们是否已根据自己的证书验证 OTP 是否确实正确编程？

此致、

Prashant

您好 Prashant：  

>如果客户获得了"成功编程密钥"、他们是否已验证 OTP 是否已根据其证书正确编程？
今天验证了 OTP 已成功编程、且 SMPK 和 BPMK 密钥的哈希均正确。  

>客户是否验证 print 语句没有执行、因为执行卡在 DebugP_assertNoLog 语句中、还是只是推测？
有一个 DebugP_log()应该在  DebugP_assertNoLog 行之后执行、但它没有被打印出来。 在 DebugP_LOG()之后有一个 GPIO 切换,也没有被执行(这是观察到的)。 在我们应该接收的"Success Programming Keys"和 DebugP_LOG()之间只有这个断言。  
DebugP_assertNoLog ((STATUS == SystemP_SUCCESS)&&((respParam.flags & TISCI_MSG_FLAG_ACK)== TISCI_MSG_FLAG_ACK))；  

我们已在另外两个已启用 syslog 的主板上进行了测试、但我们无法重现相同的问题。  我们正在尝试在同一个板上重现问题、到目前为止还没有运气。  

谢谢！  
Hong  

您好 Prashant：  

我 只能在使用 Keywriter 的相同二进制的板上重现相同的问题。 但添加 syslog 打印后、未发生此问题。  

谢谢！  
Hong  

您好、Hong：

您是否可以使用调试器连接到 R5FSS0-0内核并通过加载 Keywriter 符号来检查内核卡住的位置？

否则、您也许可以 按如下方式打印标志：

DebugP_log("flags: %d\r\n", response.flags);

在任何情况下、也请共享 Keywriter 日志(UART0)。

此致、

Prashant

您好 Prashant：  

我只幸运地重现了这个问题,但后来无法重现。 我在该设置中没有 JTAG 调试器。  


成功案例的 UART0日志：

找到的密钥证书：0x7005xxxx

Keywriter 调试响应：0x0

成功编程密钥

将 GPIO0_xx 设置为低电平以禁用 VPP

对于失败的情况：

找到的密钥证书：0x7005xxxx

Keywriter 调试响应：0x0

成功编程密钥

=>此处缺少最后一行。  当我们上次测量 VPP 时、可以看到 VPP 没有被禁用。

谢谢！  
Hong

Unknown 说：

我只有一次机会重现此问题、但随后无法重现。 我在该设置上没有 JTAG 调试器。

如果没有其他调试信息、则我们在这里无法采取太多措施来找出问题的根本原因。

我刚浏览了 Keywriter v09_01_00、看到 UART0配置为中断模式、这可能会由于 UART 勘误表而导致问题。 请在轮询模式下配置 UART0、然后查看问题是否再次出现。

如果仍然如此、请添加如下调试打印内容：有关标志值的打印、如果问题再次出现、请提供引导日志：

否则、有 Keywriter v10.00.08可用、因此您也可以进行试用。

此致、Prashant

您好 Prashant：  

我不知道有一个 UART 勘误表要求 UART 在轮询模式下运行、您能说明一下吗？

我只知道此 UART 错误、但仅限于 ROM 代码。  


我将尝试更改为轮询模式、但问题是低重现率、即使测试通过、我也不知道这是否真的能解决问题。  

谢谢！  
Hong  

您好 Prashant：  

对于 SYSFW 用于输出日志的 UART1接口、鉴于我们无法访问 UART1、我们不能在 Keywriter 中配置 UART1吗？   从 Keywriter 中的 example.cfg 中删除 UART1是否会导致 SYSFW 失败？


非常感谢、  
Hong  

您好！

Unknown 说：

我只知道此 UART 错误、但这仅限于 ROM 代码。

勘误表 i2371仅适用于 ROM。 但此勘误源于勘误表 i2310、它会影响在中断模式下使用 UART 的任何操作。

https://www.ti.com/document-viewer/lit/html/SPRZ457I#GUID-C3F24986-5AED-422A-ABE2-9952EFCE1E58/TITLE-SPRZ455I2038

Unknown 说：

将 UART1从密钥编写器中删除 example.cfg 会导致 SYSFW 失败吗？

您可以从 SysConfig 中删除 UART1。

此致、

Prashant

您好 Prashant：  

感谢您提供的信息。  

我们删除了 UART0 ISR 启用、并 从 keywriter 的 example.syscfg 中删除了 UART1、并努力使用此更新运行一些循环测试。 到目前为止、完整性检查看起来很好。  

谢谢！  
Hong  

您好、Hong：

Unknown 说：

我们删除了启用 UART0 ISR 并 从 example.syscfg 中删除了适用于 Keywriter 的 UART1、并着手使用此更新运行一些循环测试。 到目前为止、健全性检查看起来很好。

这听起来不错。

请注意、 默认情况下 Keywriter v10.00.08将 UART 配置为轮询模式。 最好迁移到最新版本以提高稳定性。

此致、

Prashant

您好 Prashant：  

从最新的测试中、我注意到了 USB 引导、即使在为 UART0禁用 ISR 后、Keywriter 也可能会在不同的位置挂起。 我们为此问题创建了另一个线程。 我认为这个问题可能是相关的。  

BTW、对于 Keywriter v10.00.08、我看到同时支持组合模式和传统模式。 我们是否可以在用例中使用传统模式？  

谢谢！  
Hong  

Unknown 说：

BTW、对于 keywriter v10.00.08、我看到它同时支持组合模式和传统模式。 我们是否可以在用例中使用旧模式？[/QUOT]

仅对于在早期版本中使用 JTAG 来运行 Keywriter 的客户、才支持 keywriter v10.00.08中的旧模式。

强烈建议使用组合的引导流程。

您好、Hong：

请告知我们问题是否已解决、无需进一步的支持。

谢谢！