[参考译文] AM6442：访问 Cortex-M3 时、程序停止且无响应

您好 Kanae、

M3 内核是供客户使用的黑盒。

M3 内核是安全内核、用户无法将调试器连接到 M3 内核。

我正在将此主题转移给 Eth 专家、以便对 EnetAppUtils_setDeviceState API 功能进行评论。

此致、

Anil.

尊敬的 Anil：

感谢您的答复。
我正在 等待 Eth 专家的答复。

我再次 告知您更多信息、并要求回答以下问题。

其他信息：
-产品在大规模生产中出现故障
-目前,问题发生在一个板上。 发生频率为 100%。  
使用的 TI RTOS SDK 版本是 MCU+ SDK 9.1.0.41

Q1：我们想检查 Cortex-M3 (DMSC-L) 是否正常工作。
   Cortex-M3 这次没有做出响应、可能是什么原因？

Q2：在 4.6.3 OSPI/QSPI/SPI 引导参数表的表 4-45 中
   (TRM：spruim2h.pdf：p.2065)、默认值描述为
   “来自引脚“。  您能否提供参考、说明引用了哪些引脚
   确定默认值？

某些设备正常启动、其他设备停止出现上述症状、我们询问此问题以确定原因。
如果您需要任何其他信息、请告知我们。

此致、
Kanae

尊敬的 Kanae：

API “EnetAppUtils_setDeviceState()“是一个 API、它请求 DM 内核设置/更新给定设备 ID 的设备状态。 在此用法中、它将是 CPSW。 由于该 API 发送 更改器件电源状态的请求、因此它将等待设备管理器的响应。 当您提到客户正在尝试访问 M3 时、我假设客户正在连接到内核、这将使内核处于停止状态。 但是、由于在 M3 内核上运行的器件管理器暂停、API 将等待超时。 如果我的理解不正确、即 M 内核已停止、那么我们必须重新创建问题以更好地理解这一点。

如果 API 超时且没有停止 M3 内核、请提供有关我们如何重新创建问题的详细信息。

谢谢。此致、
Teja。

尊敬的 Teja：

感谢您的答复。

我们的客户希望确保如何确定 M3 是否处于停止状态。

当您声明在 M3 内核上工作的设备管理器已停止且 API 应等待超时时时、您是否意味着 M3 已停止？

关于客户情况的附加信息；

-我们知道 M3 核心是一个黑盒。 我们不是试图调试问题、而是找出我们开发的电路板出了什么问题、为了猜测问题、我们要求提供有关 M3 未响应原因的信息。

-我们目前正在生产大约 1000 个。 我们已确认、只有 1/160 个主板经过测试、发现有缺陷。

-有缺陷的产品和良好的产品在设计上没有差异。 此外、由于使用同一电源执行操作检查、因此运行环境没有差异。

-电路板是 OSPI 引导,这个问题发生在 OSPI 引导,但它工作正常,当使用 SD 卡引导。 因此、我们正在查询表 4-45 中的引导参数表。

Q1：我们想检查 Cortex-M3 (DMSC-L) 是否正常工作。
   Cortex-M3 这次没有做出响应、可能是什么原因？

Q2：在 4.6.3 OSPI/QSPI/SPI 引导参数表的表 4-45 中
   (TRM：spruim2h.pdf：p.2065)、默认值描述为
   “来自引脚“。  您能否提供参考、说明引用了哪些引脚
   确定默认值？

此致、
Kanae

尊敬的 Kanae：

当您声明在 M3 内核上工作的设备管理器已停止并且 API 应等待超时时时、您是否表示 M3 已停止？

我假定客户正在尝试连接到核心、此时出现问题。 如果 DM 内核已暂停或运行到置位状态、则从以太网 API 看到的行为符合预期。 如果应用按原样、即使在自由运行的情况下、我们也可能不得不怀疑  Cortex-M3 (DMSC-L) 内核存在问题。  

我们想检查 Cortex-M3 (DMSC-L) 是否正常工作。
   Cortex-M3 这次没有做出响应的原因可能是什么？

正如 Anil 之前提到的、M3 内核是安全内核、客户无法将调试器连接到该内核。 这里要做的一项检查是、来自不同模块的其他 sci-client 请求是否在以太网 API 无法获得响应时获得响应？ 您能在您的设置中检查一下吗？

（在 4.6.3 OSPI/QSPI/SPI 引导参数表的表 4-45 中）
   (TRM：spruim2h.pdf：p.2065)、默认值描述为
   “来自引脚“。  您能否提供参考、说明引用了哪些引脚
   确定默认值？

我必须通过我们的专家进行测试、然后返回给您。 请在一天内回复

谢谢。此致、

Teja。

尊敬的 Teja：

感谢您的答复。

客户知道调试器无法访问 M3 内核、
因此、我想让他们执行您提到的检查。
在此之前、我想澄清这项检查的细节。

Teja 说：
“此处要进行的一项检查是、来自不同模块的其他 sci-client 请求是否会在以太网 API 无法获得响应时获得响应？ 您能在您的设置中检查一下吗？“

关于这一点、您的意思是：

1. 检查此行为在其他正常（无故障）电路板上是否正常工作？
   或

2. 要检查连接到当前故障电路板的不同模块的其他 sci-client 请求是否得到响应？

我正在 等待您的专家支持团队关于部分的回复 4.6.3 OSPI/QSPI/SPI 引导参数表 。

感谢您的持续支持。

此致、
Kanae

尊敬的 Kanae：

关于这一点、您的意思是：

1. 检查此行为在其他正常（无故障）电路板上是否正常工作？
   或

2. 要检查连接到当前故障电路板的不同模块的其他 sci-client 请求是否得到响应？

我想检查选项 (2)、以检查连接到当前故障电路板的其他模块。 我假设客户已经检查了良好电路板上的行为。 如果没有、请同时查看。  

我们确认只有 1/160 块电路板经过测试、发现有缺陷

我还想了解您观察到的确切故障标准是什么。 我印象中、以太网 API 故障是您观察到的故障/缺陷。

我正在 等待您的专家支持团队关于该部分的回复 4.6.3 OSPI/QSPI/SPI 引导参数表 .

我将暂时将该线程重新分配给专家、同时我还将检查与以太网相关的线程。

谢谢。此致、
Teja。

您好  Kanae、

上述建议来自 Teja。 我们需要发送另一个 SCI 调用来检查 M3 内核是否正在响应。

例如、调用 SoC_moduleGetClockFrequency API 可读取任何 IP 频率、此测试用例确认 M3 内核是否工作正常。

我正在 等待您的专家支持团队关于部分的回复 4.6.3 OSPI/QSPI/SPI 引导参数表 。

如果 SOC 进入默认引导模式而不是监控引脚值、您也可以检查 SBL 日志、此日志包含有关实际引导模式或默认引导模式下 SOC 的信息。

我会将您的问题路由给 SBL 专家。

此致、

Anil.

尊敬的 Teja：

感谢您的答复。

我已要求我们的客户检查是否正确响应了连接到主板的其他模块的 sci-client 请求（该模块现在导致问题）。
但是客户表示、
“我们将看到我们是否可以确认这一点、但我们的固件没有通过 sci-client 显式请求 M3 内核；它
通过 sci-client 搜索请求会很困难、因为这会是对 SDK API 的内部调用。 很难通过 sci-client 搜索请求。“

已从客户收到与上述检查相关的以下请求。

我的第一个问题
・在 DMSC 固件启动后、SBL 是否访问 Cortex-M3 (DMSC-L)？
・FreeRTOS 在启动时是否访问 Cortex-M3 (DMSC-L)？
我认为这些问题将确认相同内容、您能否提供作为样片提供的项目信息？

Teja 说：
我还想了解您观察到的确切故障标准是什么。
我印象中、以太网 API 故障是您观察到的故障/缺陷。

我们的客户认为这是失败
当执行 EnetAppUtils_setDeviceState() 时、程序无法在 MCU+ SDK 的 SCI 客户端 Sciclient_pmGetModuleState () 的 API Sciclient_pmGetModuleState () 中等待 Cortex-M3。 在 API Sciclient_pmGetModuleState() 中、因为程序不接收来自 Cortex-M3 的任何响应、并且程序会停止、直到超时为止。

请注意、在正常的电路板上、程序不会停止。
此外、上述问题在 OSPI 引导中发生、但当我们在 SD 引导中尝试时、不会发生上述问题。

此致、
Kanae

尊敬的 Anil：

感谢您的答复。

阿尼尔说。
如果 SOC 进入默认引导模式而不是监控引脚值、您也可以检查 SBL 日志、此日志包含有关实际引导模式或默认引导模式下 SOC 的信息。

引导插针设置已正确加载到客户的系统上。 但是、当在同一电路板上运行 OSPI 引导时、该问题会出现、并且在同一电路板上尝试 SD 引导时、该引导工作正常。
我们不确定这是否与问题的原因有关、但我们将此报告为目前的情况。

如果该客户的 QSPI 引导设置为默认引导模式（我们不确定它是哪种模式...）、则可能是引导本身会失败？

此致、
Kanae

尊敬的 Teja：

以下是有关先前客户申请的一些附加信息。

***
这一次我们想检查 EnetAppUtils_setDeviceState () 是否是启动后第一次访问 M3 内核,因为我们没有收到来自 M3 内核的任何响应。

如果没有通过 sci-client 的请求（访问 M3 内核）、这是第一个请求、因此我认为您需要通过 sci-client 尝试另一个请求。
此外,我认为,如果有一个请求,这将导致你下面要求的确认。

Teja 说：
“此处要进行的一项检查是、来自不同模块的其他 sci-client 请求是否会在以太网 API 无法获得响应、您能否在您的设置中检查此情况？“

我们假设在示例项目中已理解 TI、那么您能否向我们提供信息以检查 EnetAppUtils_setDeviceState () 是否在启动后首次访问 M3 内核？

此致、
Kanae

尊敬的 Kanae：

我正在 等待您的专家支持团队关于该部分的回复 4.6.3 OSPI/QSPI/SPI 引导参数表 .

在引导参数表中、从引脚建议此参数的值取决于引导模式引脚配置（其引脚为引导模式引脚）

那么、您能否提供信息来检查 EnetAppUtils_setDeviceState () 是否在启动后首次访问 M3 内核

我认为这是第一个向 DMSC (M3) 内核发出请求的 API、SBL ( OSPI/QSPI) 调用 Sciclient_getVersionCheck API 要向 SYSFW（在 DMSC 上运行）发送获取版本命令、您应该能够在 SBL 日志中看到 SYSFW、如下所示： AM64x MCU+ SDK：SBL OSPI Multi-Partition

如果此版本检查有效、则意味着 SYSFW 已正确加载到 DMSC 中并且可以正常工作、因此我认为 DMSC 内核本身没有任何问题、

请注意、在良好的主板上、程序不会停止。

您能告诉我、程序正常运行的主板（称为良好主板）与程序在调用  EnetAppUtils_setDeviceState 后卡住的主板之间是否有任何硬件更改？

此致、

会面。

尊敬的会议：

感谢您的答复。
信息将与我的客户共享。

满足上述要求；
在引导参数表中、从引脚建议此参数的值取决于引导模式引脚配置（其引脚为引导模式引脚）

4.6.3 关于 OSPI/QSPI/SPI 引导参数表、我知道“来自引脚“似乎取决于引导模式引脚配置、但每个参数的相关性不明确。
例如、对于引导模式引脚 (T20；GPMC0_AD1/BOOTMODE01)、是否意味着反映了表 5-607 PADMR_MCU_PADCONFIG16 寄存器字段说明中的设置？
是否有一个连贯的文档阐明每个参数值的关系及其含义？

满足上述要求；
您能否告诉我、程序正常运行的主板（称为良好的主板）与程序在调用 EnetAppUtils_setDeviceState 后卡住的主板之间是否有任何硬件更改？

我之前说过、“故障电路板“和“正常电路板“之间没有设计（硬件）差异或操作环境差异。

此致、
Kanae

尊敬的 Kanae：

EnetAppUtils_setDeviceState 不是应用程序中预期的第一个 SCI 调用。 在应用程序启动期间、将有许多其他来自其他驱动程序的 SCI 调用。 在一个特定的电路板中、只有 CPSW 没有良好响应的可能性很小。

此致、
Teja。

尊敬的 Teja：

感谢您的支持。
我知道 EnetAppUtils_setDeviceState 不是应用程序预期的第一个 SCI 调用。
我已让客户按照会议的建议检查 SBL 日志。

如果需要进行任何其他检查来确定此问题的原因、请告知我们。

此致、
Kanae

尊敬的 Kanae：

要确认这是否是专门与以太网相关的问题、您可以从应用中移除以太网软件以进行测试、然后查看您的应用是否可以正常工作。

4.6.3 关于 OSPI/QSPI/SPI 引导参数表、我知道“来自引脚“似乎取决于引导模式引脚配置、但每个参数的相关性不明确。
例如、对于引导模式引脚 (T20；GPMC0_AD1/BOOTMODE01)、是否意味着反映了表 5-607 PADMR_MCU_PADCONFIG16 寄存器字段说明中的设置？
是否有一个连贯的文档阐明每个参数值是如何关联的以及它是什么？

请参阅第 4.4.1 节。为此、您将找到有关 SPI 引导模式 (OSPI/QSPI) 的详细信息。 在这里、您可能能够找到有关一些引导参数的一些详细信息、我们以 Read Cmd 为例、对于 OSPI、它为 0x8B、对于 QSPI、它为 0x6B。

此致、

会面。

尊敬的会议：

感谢您的答复。

满足上述要求；
我认为这是第一个向 DMSC (M3) 内核发出请求的 API、SBL (OSPI/QSPI) 调用 Sciclient_getVersionCheck API 要向 SYSFW（在 DMSC 上运行）发送获取版本命令、您应该能够在 SBL 日志中看到 SYSFW、如下所示：AM64x MCU+ SDK：SBL 日志中的 SYSFW：AM64x MCU+ SDK： SBL OSPI 多分区

以下是客户确认上述内容的结果

我在 EnetAppUtils_setDeviceState () 之前运行了 SOC_moduleGetClockFrequency、这确认了问题。
结果完全相同：没有来自 M3 内核的响应。
通过以下设置执行时钟读取。
moduleID：TISCI_TIMER0
clockID：TISCI_DEV_TIMER0_TIMER_HCLK_CLK

您能否继续向我们提供有关导致 M3 内核无法响应的原因的信息？

此致、
Kanae

尊敬的 Kanae：

请要求客户共享 SBL 日志。

此致、

会面。

尊敬的会议：

感谢您的支持。

我们的客户已验证 M3 内核正在工作。
SoC_moduleGetClockFrequency 已运行
在有问题的 EnetAppUtils_setDeviceState() 之前、结果完全相同、
M3 内核无响应。
要读取的时钟
moduleID：TISCI_TIMER0
clockID：TISCI_DEV_TIMER0_TIMER_HCLK_CLK

请继续提供有关导致 M3 内核未响应的原因的信息。

这是来自我们客户的 SBL 日志。
e2e.ti.com/.../SBL_5F00_OSPI.txt

此致、
Kanae

尊敬的 Kanae：

根据 SBL 日志、SBL 似乎已正确加载 SYSFW、并且 DMSC 内核正在运行。 现在问题可能与  EnetAppUtils_setDeviceState 提出的特定请求有关、请给我一些时间在内部讨论此问题、并给您一些更新。

此致、

会面。

尊敬的会议：

感谢您的答复。
我会将 您的情况告知我们的客户。
请继续与我们联系。

我们客户从稍微不同的角度提出了另一个问题。

问：M3 内核可能会受到 CPU 引脚状态的影响、例如中的焊料不良
CPU、它是导致 M3 内核没有响应的一个因素？

目前、发生率为 1/160、我们想考虑 CPU 故障、安装故障等的可能性

此致、
Kanae

尊敬的会议：

感谢您的支持。
您能告诉我们您目前的讨论状态吗？

我想与您分享我们客户调查的结果。
他们发现、当他们在 hello_world.c 中将以下 API 添加到 hello_world.c 中的 hello_world_main () 中时、该 API 作为示例提供、而不是由客户开发的固件、来自 M3 内核的响应消失了。
在我们的普通板上、响应是正常的。

ClockP_USleep(1000*1000);
SoC_moduleGetClockFrequency (TISCI_DEV_TIMER0、TISCI_DEV_TIMER0_TIMER_HCLK_CLK、&freq)；

基于上述情况、您认为 CPU 中可能存在某种异常吗？

如果我们的客户需要检查任何其他要点、请告知我们。
当您希望回复时、有必要通知我们的客户、
那么、您能否最迟在本周结束前联系我们？

此致、
Kanae

尊敬的会议：

作为额外信息、普通电路板之间没有差异
和有缺陷的电路板在电源顺序等方面的问题

此致、
Kanae

尊敬的 Kanae：

他们发现、当他们在 hello_world.c 中将以下 API 添加到 hello_world.c 中的 hello_world_main () 时、来自 M3 内核的响应消失了、该 API 以示例的形式提供、而不是由客户开发的固件。

这是否意味着当您在 hello world 示例中添加此请求时、即使是默认示例也停止工作、它也会卡在 Sciclient_waitForMessage 中？  

我的理解是、如果您能够使用 SBL 获取 SYSFW 版本、则 SYSFW 已启动并正在运行、并且在向 SYSFW 发出有效请求时不应遇到问题。 我不知道为什么您在这些请求中会遇到这一问题、在特定的主板上、您可以要求他们 在应用程序中添加 Sciclient_getVersionCheck ()、这将确认整个 SYSFW 本身是否有问题、还是仅针对某些特定的请求。 如果这样确认这只是  EnetAppUtils_setDeviceState 等特定请求的问题、那么我们可以进一步分析什么硬件/软件故障会导致这种情况。

此致、

会面。

尊敬的会议：

感谢您的答复。
以下是我客户的评论。

会见时说：
这是否意味着当您在 hello world 示例中添加此请求时、即使是默认示例也停止工作、它也会卡在 Sciclient_waitForMessage 中？

正确。

此外、我已确认您所指示的项目的运行情况。
我使用的是 Hello World 示例。

我将以下内容添加到 Hello_world.c 中的 hello_world_main (void *args) 中
并确认操作。

*********************************************************
DebugP_log（“Hello World！\r\n“）；

ClockP_USleep (1000*1000)；/*睡眠 1 秒*/
Status = Sciclient_getVersionCheck (1)；

对于 (cnt = 1；；cnt++)
｛
ClockP_USleep (1000*1000)；/*睡眠 1 秒*/
RET = SOC_MODULEGetClockFrequency (TISIC_DEV_TIMER0、TISCI_DEV_TIMER0_TIMER_HCLK_CLK、&freq)；
IF (RET = 0)
DebugP_log（“查询时钟频率！ CNT：0x%x、freq：%llu\r\n“、cnt、freq)；
}
*****************************************************

因此、没有收到来自 M3 内核的响应。 我将共享日志文件。

e2e.ti.com/.../NG_5F00_log.txte2e.ti.com/.../OK_5F00_log.txt

 如果有任何其他事项需要检查、请告诉我。   

此致、
Kanae

尊敬的会议：

感谢您的支持。

您能否就上述客户验证结果向我们提出您的意见？

如果您希望我们检查任何其他信息以确定 M3 不工作的原因、请告知我们。

我需要通知我的客户、因此如果需要一些时间来回答、
请至少告诉我您何时可以回复？

此致、
Kanae

尊敬的 Kanae：

我看到他们目前使用的是 9.1.6 版本、您能建议客户尝试使用最新的 MCU+SDK 版本进行一次测试、看看他们是否仍然会遇到相同的问题。

此致、

会面。

尊敬的会议：

感谢您的答复。

这是否意味着当前使用的最新 SDK 和 MCU+ SDK 9.1.0.41 发生了影响 M3 运行的更改？
如果是、请提供具体更改的详情？

此致、
Kanae

您好、

SYSFW 版本中。 包括 9.1.0、由于初始化顺序不正确而出现问题、此问题已在 10.0 版中得到修复、请查看发行说明： https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/RELEASE_NOTES_10_00_00_PAGE.html

目前、我不确定这是否会导致您的案例中的问题、但使用较新的 SDK 进行一次测试将阐明这一点、较新版本还将包含一些除此之外的其他修复、因此最好使用最新的 SDK。 他们仍在使用 9.1 版本的原因是什么？

此致。

会面。

尊敬的会议：

感谢您的答复。

以下是我的客户的绩效检查结果。

使用最新的 SDK 11.01.00.17、我们 通过将 Sciclient_getVersionCheck () 添加到 helloworld 来执行性能检查、就像我们对 SDK 9.1 所做的那样。
 不再出现 M3 内核无响应的问题。

作为参考、我们比较了每个版本的性能。
SDK 9.1：NG
SDK 10.0：NG
SDK 10.1：正常
SDK 11.1：好的

我们将共享每个版本的日志以供您参考。

e2e.ti.com/.../SDK_5F00_log.zip

 SDK 10.0 和 SDK 10.1 的更新似乎出现了问题。

由于这已经是已发货的大规模生产产品、
很难仅通过升级 SDK 版本来解决该问题。
考虑到目前的情况、如果您能向我们提供有关导致 M3 核心停止响应的因素的信息、我们将不胜感激。
我们认为、存在个别差异、涉及一些因素。

关于使用 9.1 的原因、我们设计的电路板评估由最终用户在去年夏天完成。
当时使用的固件的 SDK 版本为 9.1。 当时、M3 内核停止响应没有问题。   

如上所述、已通过 SDK 10.0 和 SDK 10.1 的更新确认了更改。
您能否提供可能导致 M3 内核在此差异中停止响应的任何因素？

此致、
Kanae

尊敬的会议：

感谢您的支持。

您能否就上述客户验证结果向我们提出您的意见？

如果您希望我们检查任何其他信息、以确定 M3 不工作的原因、
请告诉我们。

我需要通知我的客户、因此如果需要一些时间来回答、
请至少告诉我您何时可以回复？

此致、
Kanae

尊敬的会议：

我需要向客户报告此情况、您能告诉我状态吗？
如果客户方面需要确认、请告知我。

此致、
Kanae

尊敬的 Kanae：

每个版本的版本说明中通常都提到了这些更改、例如我提到的 PLL 初始化序列问题已在 v10.0： https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/RELEASE_NOTES_10_00_00_PAGE.html#autotoc_md154 中修复

我检查了您提供的 V10.1 日志、在我看来日志来自版本 10 本身、因为日志显示 DMSC 版本 10.0.8。

如果您无法迁移到更新的 SDK 版本、则可以按照以下指南在旧 SDK 上获取 SDK V10 的 PLL 更新： https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/SYSFW_PLL_UPDATE_GUIDE.html

此致、

会面。

尊敬的会议：

感谢您的答复。

关于您提到的问题、V10.0 和 V10.1 之间存在差异、
但是、它们使用相同的 DMSC、因此很可能是 PLL 初始化序列有问题。

此外、关于这个 PLL 初始化序列问题、是否与 AM64x 勘误表 I2424 相同？

https://www.ti.com/document-viewer/ja-jp/lit/html/SPRZ457I#GUID-700AF975-4E55-4306-BBD3-5E7A3E807E05/TITLE-SPRZ455I2038

此外、关于在旧 SDK 上获取 V10 PLL 更新、
这是确认故障排除请求吗？

此致、
Kanae

尊敬的 Kanae：

此外、关于这一 PLL 初始化序列问题、它是否与 AM64x 勘误表 I2424 相同？

是这是正确的、此问题已在较新的 SYSFW 版本中修复。

另外、关于在旧 SDK 上获取 V10 PLL 更新、

您可以尝试此操作一次、查看集成较新的 SYSFW 是否解决了此问题、如果集成了更新的 SYSFW、则可确认问题与 PLL 初始化相关、如果集成了、则客户可以集成较新的 DMSC 固件以避免任何进一步问题。

此致、

见面、

尊敬的会议：

感谢您的支持。

会见时说：
您可以尝试此操作一次、查看集成较新的 SYSFW 是否解决了此问题、如果集成了更新的 SYSFW、则可确认问题与 PLL 初始化相关、如果集成了、则客户可以集成较新的 DMSC 固件以避免任何进一步问题。

我的客户已检查以上内容、结果如下。

上述验证结果显示 M3 内核停止响应。 使用之前已验证的 Hello 程序。 日志已附加。 (SDK9_01_update__dDMSC_ABI_txt)

e2e.ti.com/.../SDK9_5F00_01_5F00_update_5F00_DMSC_5F00_ABI_5F00_log.txt
为了进行比较、还附加了之前正常的日志。 (OK_LOG.txt)e2e.ti.com/.../8203.OK_5F00_log.txt

根据这些结果、这个问题与勘误表 i2424 是否不同？

此致、
Kanae

尊敬的会议：

感谢您的支持。

在这方面是否有任何进展？
由于我需要向客户报告、您能否告诉我您何时可以提供回复？

此致、
Kanae

尊敬的 Kanae：

您可以要求他们启用 SYSFW 日志并与我共享这些日志、这些日志可能有助于捕获问题。 您可以参考以下有关如何启用 SYSFW 跟踪的指南：  【常见问题解答】AM64x/AM243x：如何在 AM64x/AM243x 器件上启用 SYSFW 跟踪 

此致、

会面。

尊敬的会议：

感谢您的支持。
我将要求我的客户与我们共享日志。

此致、
Kanae

尊敬的会议：

关于启用 SYSFW 跟踪、对于 AM64x、指令指定了将输出记录到 UART1。
但是、客户的电路板仅连接到 UART0。  
是否有方法可以获取 SYSFW 日志、而不是通过 UART1 获取？  
您能否提供具体的替代解决方案？

此致、
Kanae

您也可以从跟踪内存缓冲区位置获取日志、对于 AM64x、此缓冲区位于 0x44043000、大小为 0x0FE0： https://software-dl.ti.com/tisci/esd/latest/4_trace/trace.html#trace-memory-buffer-location

此致、

会面。

尊敬的会议：

感谢您的支持。

我们已从您提供的跟踪内存缓冲区中的指定位置获取数据。
这是使用我们之前验证的 Hello 程序停止来自 M3 内核的响应时的数据。

e2e.ti.com/.../Trace_5F00_Memory_5F00_Buffer_5F00_0xFE0_5F00_R5_5F00_0_5F00_0.txt

我们还从第二个 R5F (R5_0_1) 获取数据并将与您共享。   

e2e.ti.com/.../Trace_5F00_Memory_5F00_Buffer_5F00_0xFE0_5F00_R5_5F00_0_5F00_1.txt

这些数据是否有助于澄清问题的原因？

此致、
Kanae

尊敬的会议：

感谢您的支持。

在这方面是否有任何进展？
您能告诉我什么时候可以提供回复吗？

此致、
Kanae

尊敬的会议：

在这方面是否有任何进展？
请告诉我您对数据的调查的当前状态
从跟踪存储器缓冲区中的指定位置开始、以及何时可以提供响应？

这是我的客户的当前状态。

到目前为止、我们已经测试了 1080 台设备、而 M3 核心没有响应的设备有 17 台。

此致、
Kanae

Kanae、这真的很难调试、因为只有部分器件面临该问题。 您共享的 TIFS 日志显示了防火墙异常、因为 R50-1 尝试访问 DMASS0_RINGACC_CFG 区域、如果所有硬件中使用了相同的软件、则您应该在所有器件中观察此异常、您可以共享从获取的 TIFS 日志 正常工作的器件 我们可以对它们进行比较、看看是否发现了相同的问题。  

最初、我认为这可能是 PLL 初始化序列的问题、但正如您提到的、即使在更新到 MCU+SDK 10.0 后、您也会遇到这个问题、这可能不是问题。 根据您的评论、我看到在使用 10.1 以后的 MCU+SDK 版本时问题已经解决、我们是否可以尝试集成 10.1 以后的 SYSFW、就像我们在 10.0 之后的做法一样？ 请注意、用于 10.0 和 10.1 的 SYSFW 版本不同、10.1 使用 DMSC v10.01.08、此测试将帮助确定这是否与 SYSFW 相关。 如果这不是与 SYSFW 相关的问题、那么我们可以尝试查看其他原因、以下是正常工作设备中的 TIFS 日志将提供帮助的位置、因此请也分享这些日志。

尊敬的会议：

感谢您的答复。

满足上述要求；
我们是否可以像对 10.0 一样尝试集成版本 10.1 的 SYSFW？
请注意、用于 10.0 和 10.1 的 SYSFW 版本不同、
10.1 使用 DMSC v10.01.08、此测试将有助于确定这是否是与 SYSFW 相关的问题。

我假设 SYSFW 10.0 和 10.1 基本相同。
我附加了 SDK10_00_log.txt、SDK10_01_log.txt、以供您参考
这与我两个月前发送的“sdk_log.zip"相同“相同。

SDK10_00_log.txt
e2e.ti.com/.../SDK10_5F00_00_5F00_log.txt

SDK10_01_log.txt
e2e.ti.com/.../SDK10_5F00_01_5F00_log.txt

另外、我搜索了 SYSFW v10.01.08 以便从版本 10.1 导入、但找不到它。
SYSFW v10.01.08 是否公开提供？

满足上述要求；

如果这不是与 SYSFW 相关的问题、那么我们可以尝试查看其他原因、
以下是正常工作设备中的 TIFS 日志将提供帮助的位置、因此请也分享这些日志。

以下是您请求的日志。

Trace_Memory_Buffer_workinigDevice.txt（原始日志）
e2e.ti.com/.../Trace_5F00_Memory_5F00_Buffer_5F00_WorkingDevice.txt

workingdevice_sysfw_output.txt（后处理日志）
e2e.ti.com/.../workingdevice_5F00_sysfw_5F00_output.txt

此致、
Kanae

此外、我搜索了 SYSFW v10.01.08 以便从版本 10.1 导入、但找不到它。
SYSFW v10.01.08 是否公开可用？

您好、Kanae、我认为日志显示了 V10.0、但 MCU+SDK v10.1 实际上使用了 SYSFW V10.01.08、请在版本说明 https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_01_00_17/exports/docs/api_guide_am64x/RELEASE_NOTES_10_01_00_PAGE.html#autotoc_md129 中了解这一点 

为此、可以从 MCU+SDK V10.1 复制 SYSFW、方法与对 SDK V10.0 相同。  

从您为工作设备共享的日志中、您没有看到防火墙异常、此防火墙异常很可能是某些设备的 SYSFW 崩溃的原因、希望从 SDK V10.1 集成 SYSFW 修复这些问题、请请求他们尝试一下并更新结果。

此致、
会面。

尊敬的会议：

感谢您的支持。

版本说明中确实显示“DMSC 固件 v10.01.08“、
但实际上 SDK10_01_log.txt 显示了
“DMSC 固件版本 10.0.8--v10.00.08 (Fiery Fox)。“

这是否意味着日志不正确？
或者客户是否未正确使用 SDK10_01？

此致、
Kanae

这是否表示日志不正确？
或者客户是否未正确使用 SDK10_01？

我最后还观察到了这一点,主要是日志问题,没有重大问题,不管怎样,请他们集成 SDK V10.1 的 SYSFW 并进行测试。

尊敬的会议：

感谢您的答复。
以下是我的客户的确认结果。

我们集成了 SYSFW V10.01.08 并附加了测试期间获得的日志。
而不是使用可用的官方版本 MCU_PLUS_SDK_am64x_10_01_00_32
从 Texas Instruments 网站、我们使用以下 GitHub 存储库中的文件重建 SDK：

github.com/.../am64x_am243x

使用重建的 SDK 验证操作后、我们发现日志输出保持不变。
系统仍在 Sciclient_getVersionCheck(1) 调用时挂起。
（请参阅附件：SYSFW10_01_log.zip 中的 inSYSFW10_01_log.txt）

e2e.ti.com/.../SYSFW10_5F00_01_5F00_log.zip

此外、为了便于参考、我们还包括了 从每个内核收集的解析的跟踪存储器缓冲区输出、该输出使用分析工具 sysfw_trace_parser.py 进行处理。

此致、
Kanae