[参考译文] AM2431：软件复位

Larry、您好！

感谢您访问德州仪器 E2E 支持论坛。

我们的域专家今天到场、因此将推迟回复。 请期待一两天内得到回复。

此致、

图沙尔

Larry、您好！

新的更新固件通过应用程序接收、并将其保留在外部闪存中。

因此、现在您需要重置 SOC、以便 SBL 将尝试在 SOC 上加载并运行新的应用程序。

在64X/243中、复位操作将由 DMSC 内核控制。 因此、您无需控制任何寄存器即可进行 SOC 复位。

请使用以下函数重置 SOC。

Sciclient_pmDeviceReset  ()。

我清楚地解释了如果我们调用上述 API、寄存器将会产生什么影响。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1237209/faq-am64x-how-to-reset-warm-reset-the-soc sciclient_pmDeviceReset#4675314？tisearch=e2e-sitesearch&keymatch=Sciclient_pmDeviceReset#4675314

如果您在应用中有任何将 MCU 内核与主要域特性隔离的方法、请告诉我。

此致、

S.Anil.

尊敬的 Swargam：

感谢您的详细答复。 关于功能:Sciclient_pmDeviceReset(SystemP_WAIT_FOREVER),我已经测试了。 此函数的行为与我上面提到的对寄存器内容的修改相同、如下所示：

• 0x43019008 <- 0x68ef3490
• 0x4301900c <- 0xd172bc5a
• 0x43018170 <- 0x06

但是、此函数仍然不允许我的固件从 SBL 重新启动。 在应用程序中执行该功能后、我无法看到 SBL 启动日志。 这有其他原因吗？

我的 SBL 修改自SDK/examples/drivers/boot/sbl_ospi。 是否可能Bootloader_socWaitForFWBoot()在开始时导致堵塞？ SoC 是否未接收来自 MCU 的信号？

此致！

拉里

Larry 您好!

调用上述 API 后、已完成 SOC 复位操作。  

之后、代码引导流程将如下所示：  

复位→RBL→SBL→应用。

仍然、您无法在 SBL 上看到任何日志、那么您的代码可能会卡在 SBL 上。

您可以尝试使用以下方法调试 SBL 代码：  

添加函数  loop_forever ()  在输入 main()并编译 SBL 之后。

在 UART 引导模式下通过 UART UNIFLASH 工具将此二进制文件发送到 SOC。

接下来、将目标连接到 R50_0 (SBL 仅在 R50_0内核上运行)。

需要调试的程序已加载到器件上。 加载符号  进一步调试。

您能否确认外部 OSPI 中闪烁的图像类型？ 在应用程序运行期间是应用程序映像还是 rprc 映像？

在您通过 UART UNIFLASH 传输时，是否可以确认更新的固件是否正在运行？

此致、

S.Anil.

尊敬的 Swargam：

"Load the symbols"是什么意思？ 此"加载符号"操作是否对热复位进行了仿真？

1. 我更新的映像在 Debug 文件夹中编译和生成为 project_name.appimage.hs_fs。
2. 我可以确认更新后的固件可以正常运行、因为它与最初仅在一个日志的内容中运行的应用程序不同、我可以通过该日志来识别它。 我已经通过 UART uniflash 更新了固件并在 AM2431上运行。

此致！

拉里

Larry、您好！

如果从 UART uniflash 运行新应用程序 ,则您的应用程序映像不会有问题。

您能否确认您的 SBL 在哪里被卡住? 通过使用以下常见问题解答,您可以调试 SBL。 在您的测试后,  我们可以在您的测试中获得一些关于 SBL 在哪里被卡住进一步调试问题的见解。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1119575/faq-mcu-plus-sdk-am243x-how-to-debug-sbl_qspi-for-am263-and-am273-or-sbl_ospi-for-am243-or-an-application-which-is-booted-via-ospi-qspi-boot

此致、

S.Anil.

尊敬的 Swargam：

但是、如果我在 SBL 的最开始插入一个 while 循环、SBL 将无法继续到应用、因此我将无法执行热复位。 在这些不同的条件下、是否仍然可以重现相同的问题？ 它似乎在逻辑上不一致、不是吗？

此致！

拉里

Larry、您好！

调试 SBL 代码非常简单。 您应该按照上述常见问题解答中的简单步骤进行操作。

您无需重置任何设备、因为已更新的固件在外部存储器中可用。 您的代码在 while (1)条件下在 SBL 中挂起、现在连接调试器并按照 FAQ 加载符号。 接下来、从 while (1)条件 中退出、并在 SBL 代码挂起的位置进行进一步调试。  

如果您有一个项目、请与我分享。 从零开始满足您的要求后、我可以进行进一步调试。 这对我来说是需要时间的。

此致、

S.Anil.

尊敬的 Swargam：

由于在过去几天里我一直忙于其他工作、给您带来不便、我深表歉意。 今天、我已将while(flg)环路合并到 SBL 中进行测试。 下面是我的测试程序的详细说明：

1. 我使用 uart_uniflash 将 SBL 和应用程序刷写到 AM2431上。
2. 重新供电后、AM2431会重新启动。
3. 通过 CCS 加载符号,我观察到程序在停止0x70003524,如下图所示,确认它卡在while SBL 内的循环中。
   
4. 我修改了while循环中的标志条件以允许它退出。
5. 程序成功地完成了 SBL 逻辑并转换到应用。
6. 应用程序完成初始化后，它会执行更新固件，然后执行Sciclient_pmDeviceReset(SystemP_WAIT_FOREVER)。
7. 然后，通过 CCS 重新加载符号显示程序在停止0x418019F0。
   

此时、我无法继续进行调试。 即使尝试加载符号、也不能说明程序执行已停止的位置。 程序可能出现在未知位置、可能表明Sciclient_pmDeviceReset(SystemP_WAIT_FOREVER)未正确地重新启动 AM2431、扰乱预期的 RESET→RBL→SBL 进程、并导致程序运行到意外位置。 是否使用了错误的函数？

此致！

拉里

Larry、您好！

Unknown 说：

由于在过去几天里我一直忙于其他工作、给您带来不便、我深表歉意。 今天、我已将while(flg)环路合并到 SBL 中进行测试。 下面是我的测试程序的详细说明：

1. 我使用 uart_uniflash 将 SBL 和应用程序刷写到 AM2431上。
2. 重新供电后、AM2431会重新启动。
3. 通过 CCS 加载符号,我观察到程序在停止0x70003524,如下图所示,确认它卡在while SBL 内的循环中。
   
4. 我修改了while循环中的标志条件以允许它退出。
5. 程序成功地完成了 SBL 逻辑并转换到应用。
6. 应用程序初始化完成后、它会执行更新固件

[/报价]

直到第六点、我知道您的固件已更新并正在运行、没有任何问题。

过了一段时间,你给了,  SCiclient_pmDeviceReset、以使 SOC   则 SOC 进入 HALT 状态。

我假定您的代码滞留在 SBL 中、 因为该地址属于 ROM 地址。

是否可以共享您的应用程序和 SBL 进一步调试问题?

您是否检查下面的 API 以进行 SOC 重置？ 您没有遇到任何问题？

SoC_generateSwWarmResetMainDomain

此致、

S.Anil.

尊敬的 Swargam：

是的、我尝试过此命令、包括尝试 MCUDomain 中的函数、它们都指向相同的地址。

请提供您的电子邮件给我吗？ 我尝试压缩我的项目进行上传、但文件可能太大、无法在此处上传。

此致！

拉里

Larry、您好！

如果您在 EVM 上共享可复制的代码、这会非常有帮助。

如果您分享您的客户项目、则需要更多时间来分析问题。

请尝试在 EVM 上提供可重现的代码、并将它们连接到主题中的相同位置。

此致、

S.Anil.

尊敬的 Swargam：

有任何更新？

此致！

拉里

Larry、您好！

很抱歉、我无法检查您的问题、因为我参与了其他客户问题上报。

希望我能在下周了解一下。

同时、请提供 SBL 和应用项目的系统 cfg 文件。

此致、

S.Anil.

Larry、  

谢谢。 我可以在下星期更新您的状态

此致、  

S. Anil

Larry、您好！

我已经查看了您的 SBL 和应用配置、除 OSPI 外设之外、所有配置均正常。

您能否确认 OSPI 模块是否在应用中与我们的 DMA 一起使用？

因为您在系统配置中未启用 DMA 模式。

您会执行一个测试。 我们已经在 SBL 中初始化了 OSPI 模块并在系统配置中删除了 OSPI 外设、并尝试使用 API 在外部存储器上写入数据。 可以看到问题仍然存在。

我怀疑此问题会在应用程序中的 OSPI 初始化期间出现。

此致、

S.Anil.

尊敬的 Swargam：

关于第一个问题：
您能否确认 OSPI 模块是否在应用中与我们的 DMA 一起使用？
否、我没有在应用程序中为 OSPI 配置 DMA。 今天、我尝试在应用程序内为 OSPI 启用 DMA、然后再次测试、但仍未重新启动。

此外、我对您的观点有点不清楚。 您是否建议、由于我已经在 SBL 中初始化了 OSPI、我不应该在应用程序中再次将其初始化？ 我是否需要从应用中的 syscfg 中移除 OSPI 并照常直接调用 OSPI 的句柄来读取和删除外部闪存？

此致！

拉里

Unknown 说：

此外，我对您的观点有点不清楚。 您是否建议、由于我已经在 SBL 中初始化了 OSPI、我不应该在应用程序中再次将其初始化？ 我是否需要从应用程序的 syscfg 中移除 OSPI 并照常直接调用 OSPI 的句柄来读取和删除外部闪存？

Larry、您好！

是的、我假设您的应用在 OSPI 的初始化期间卡住。

您可以尝试在系统 cfg 中删除 OSPI 并使用直接 OSPI 调用来写入和读取操作。

否则、需要恰好在跳转到应用之前取消初始化 SBL 中的 OSPI 外设、然后在应用中重新初始化 OSPI。 这样就不会出现任何问题。

我希望您可以分享您的结果。

此致、

S.Anil.

尊敬的 Swargam：

我的应用在初始化期间不会卡住。

SBL 已初始化 OSPI 并完成检查后、它会跳转到应用程序、并且初始化 OSPI 也不会导致任何问题。 之后、我成功接收固件更新并将其写入外部闪存、没有任何问题、直到我执行 Sciclient_pmDeviceReset (SystemP_WAIT_FOREVER)；然后、我发现我的地址跳转至0x418019F0。

我可以尝试按照您建议的方式对其进行修改、但该过程被卡住的时间似乎不是在 OSPI 初始化期间、因为在我接收到固件更新之前、SBL 和应用程序都已经初始化 OSPI。

此致！

拉里

尊敬的 Swargam：

遗憾的是、从 syscfg 中移除 OSPI 会直接导致编译问题、因为 OSPI 和闪存组件是链接的。 移除 OSPI 还需要移除闪存、这会由于缺少相应函数而导致编译错误。

此外、在调试期间、在通过调试探针进行测试之前、我首先刷写 SBL_null。 SBL_null 不包括 OSPI 和闪存、因此不存在重复初始化的问题。 但是、即使在调试模式下、在执行 Sciclient_pmDeviceReset 后、该过程也仍跳到0x418019F0。 因此、我认为这可能与 OSPI 没有直接关系。

此致！

拉里

Larry、您好！

实际上、我们已经看到相同的外设在客户应用程序中造成问题。

因此、我建议在此应用相同的过程。

无论如何、您将使用 sbl_null、它不使用 ospi 并初始化所有外围设备、然后在器件复位后。 再说一次、SOC 将

0x418019F0地址。 我可以尝试在我旁边使用您的应用、而且还会分享我的测试结果。

此致、

S.Anil.

尊敬的 Swargam：

很抱歉，由于休假时间延长，响应出现延迟。 我想问一下、假设我们无法通过软件重新启动、是否可以通过硬件方式重新启动？ 从理论上讲、它应该具有相同的效果、对吧？ 我们的主要目标是使 AM2431进入 SBL (次级引导加载程序)模式、以便它可以更新应用。 这在理论上是否可行？ 如果是、我应该触发哪个引脚执行此操作？

此致！

拉里

尊敬的 Swargam：

没错；即使进行硬件复位、我仍会在0x418019F0地址结束。 更改重置方法不能解决问题。 此外、我使用 SBL_NULL 固件进行了一个实验、以在调试模式下进行测试。

如果我在执行前执行硬件复位、 Board_driversOpen();，重置将正常进行。 但是、在警报触发之后执行 Board_driversOpen();导致跳转到0x418019F0地址。 即使我立即关注 Board_driversOpen();实现 Board_driversClose();然后执行硬件复位、它仍跳至0x418019F0地址。 正如您所提到的、该问题可能与闪存有关、 Board_driversOpen()本质上调用 Board_flashOpen();，但此问题的确切原因尚不清楚。

此致！

拉里

尊敬的 Swargam：

我找到了根本原因、 我尝试将闪存协议设置从4S-4S-4S 更改为1S-1s、问题已解决。 这实际上是由不正确的闪存设置引起的。 感谢您的不懈帮助！！

此致！

拉里