[参考译文] AM2432：我们是否需要在链接器运行时环境中使用"--ram_model"选项作为初始化模型？

大家好，Moonil，

根据应用程序的需要选择启动模型。 ROM 模型在引导例行程序期间执行更多的工作。 RAM 模型在加载应用程序时执行更多工作。

如果您的应用程序可能需要频繁重置，或者是独立的应用程序，ROM 模型可能是一个更好的选择，因为启动例程将拥有初始化 RAM 变量所需的所有数据。 但是，对于带有操作系统的系统，使用 RAM 模型可能会更好。

请参阅  8.3.运行时初始化—TI ARM Clang 编译器工具用户指南 ，了解详细信息。

此致，

明

您好，Ming，

我在 SDK 中尝试了“空示例”，只在链接器选项中将 RAM 模型更改为 ROM 模型。 它接着断言如下。

请问原因是什么？ 这是我提到 MPU_init 的问题。  我想知道，由于使用 syscfg 生成的代码，SDK 中的链接器选项是否有任何限制。  

此致，

月米勒

大家好，Moonil，

我做了同样的更改(RAM 模型到 ROM 模型)，并为 AM243x 重建了 MCU+ SDK 08.01.00.36的"/empty_am243x-EVM-r5fs0-0_nortos_ti-arm-clang"，并在 AM243x EVM 上测试了它。 工作正常。

您使用的是哪种 MCU+ SDK 版本，您使用的是哪种平台的 AM243x EVM 或 LP？

此致，

明

大家好，Moonil，

我也在“/empty_am243x-LP_r5fs0-0_nortos_ti-arm-clang”中做了同样的更改，并在 AM243x LP 上进行了测试。 它的工作也很好。

确保已将 SBL_NULL 闪存到 OSPI 或 SD 卡中。 AM243x MCU+ SDK：EVM 设置(TI.com)

此致，

明

您好，Ming，  

我发现  SBL_NULL 在测试期间被另一个覆盖。 问题已解决。

是否有方法将 SBL 从 CCS 直接闪存到目标？

谢谢，

月米勒

大家好，Moonil，

您可以将引导模式设置为 UART，然后按照 AM243x MCU+ SDK：EVM 设置(TI.com)中的说明进行操作。 它将使用 SBL NULL 覆盖当前引导映像。

此致，

明

您好，Ming，  

我的问题是如何使用 CCS 菜单(如“运行->加载程序”)直接将 SBL 写入 Nor Flash，但不使用 CMD 窗口中的命令行。 如果有这样的办法，请告诉我。

我还有另一个关于“--ram_model”的问题。 当我在 CCS 中尝试“重新启动”时，分配失败，如下所示：

我猜 这是因为堆内存(“.sysmem”)在“重新启动”时未初始化。 您能否澄清原因？ --ram_model 不允许“重新启动”？  供参考，在使用“--rom_model”时，不会出现此类问题。

此致，

月米勒

切斯特，您好！

感谢您澄清两种型号初始化之间的区别。 根据您的解释，我理解使用 CCS 时，只能使用--rom_model 来避免因使用--ram_model 时“上次运行的值”而引起的混乱情况。 正确吗？

如果不使用 CCS，则使用 uart_uniflash.py 将使用“--ram_model”构建的二进制文件刷新到目标，并且目标为“热”重置，这种情况如何？ 我想“上一次跑步的值” 也可能会发生同样的情况。 您是否也能澄清此案例？

这个问题是关于产品的发行版(包括“热重置” )是否可以使用“--ram_model”构建，以及是否需要在“.sysmem”上实施其他初始化。

此致，

月米勒

大家好，Moonil，

有一个 JTAG 版本的 uniflash 程序，可以将引导映像写入 OSPI 闪存中，但它尚未包含在 MCU+ SDK 中。 计划将其包括在下一个用于 AM243x 的 MCU+ SDK 08.02.00中。 我可以向您发送 CCS 项目。

至于“重新启动”为什么对您不起作用，它完全取决于您在初始化阶段如何初始化变量。 如果您的程序在“冷重置”时依赖于 RAM 的初始值，那么您很可能会遇到“重新启动”问题，即使是“热重置”(不会重置 RAM)。

经验法则是，您需要使用附加代码(ROM 型号)或加载时间记忆库副本(RAM 型号)初始化程序中的所有重要变量/缓冲区。

此致，

明  

您好，Ming，

请发送  JTAG 版本的 uniflash 程序。 您需要我的电子邮件发送吗？

我仍然发现--ram_model 和--rom_model 都有问题。  

1) --ram_model ： 我尝试将代码初始化堆(".sysmen")如下，但当使用"-ram_model“重新启动”时，malloc()仍然失败。 如果这是您提到的初始化方式，请告诉我吗？ 否则，请分享任何示例。

2) --rom_model ： 我在--rom_model 中发现了一个问题。 闪存 SBL_NULL 后，链接器选项中带有 ROM 模型的 SDK 中的“空示例”不会声明，但 MPU 配置不正确，如下所示。 我认为原因是，SRAM (gMpuConfig) 重置后全部为零，但当在“boot_armv7r_ASM.S”中调用__MPU_init 时，gMpuConfig 尚未通过“_TI_auto_init”初始化。 我认为 MPU 必须配置 由 syscfg 生成的正确 gMpuConfig 值。 您是否可以在结束时复制此内容？ 我认为__MPU_init 函数应该在__TI_auto_init 引信后调用。 你怎么看？

 

 

此致

月米勒

大家好，Moonil，

我确实需要您的电子邮件来向您发送 JTAG 版本的 Uniflash CCS 项目。 我还将与我们的软件团队跟进您的 ROM 模型和 RAM 模型问题。

此致，

明

您好，Ming，

我的电子邮件是“moonil.heo@se.com”。

此致

月米勒

大家好，Moonil，

我已将 CCS 项目发送到您的电子邮件地址。

此致，

明

关于与--ram_model 链接时 CCS 重启功能如何失败...  切斯特·吉龙的答复是正确的。  我只能解释更多细节。

使用--ram_model 时，链接程序将.data 部分视为另一个已初始化的部分。  推定是加载程序将.data 部分复制到内存中的适当地址，就像任何其他初始化的部分，如.text (包含代码)。  CCS 执行重新启动时，会将 PC 设置为程序的起始地址。  在程序执行期间对.data 部分中的变量所做的任何更改都不受影响。

使用--ROM_model 时，.data 部分是未初始化的部分。  还有一个名为.cinit 的部分。  启动代码由链接程序配置为预期.cinit。  启动代码使用.cinit 初始化.data 部分中的所有变量。  当 CCS 一如既往地执行重新启动时，PC 将被设置为程序的起始地址。  启动代码再次运行，然后使用.cinit 部分的内容初始化.data 部分中的变量。

关于您的问题--rom_model... 我可以告诉您不要使用编译器 RTS 库附带的启动代码。  也就是说，该启动代码可能使用与编译器 RTS 库随附的启动代码相同的启动钩函数。  要查看这些函数的文档， 请在 TI ARM 编译器手册中搜索 标题为 “系统预初始化的启动钩函数”的子章节。  您的问题很可能是通过更改这些功能的实施来解决的。

谢谢，此致，

乔治

你好，乔治，

感谢您对我们的详细解释。 我似乎从您的评论和 TI ARM 编译器中理解了这两种模型。

但是，我找不到一个解决方案来使用--rom_model 正确运行 SDK 示例。 我应该修改一些代码还是更改空示例的任何链接器选项？

请告诉我，我在“2) --rom_model”中捕获的问题 是否在您的末尾重现

供参考，在将空示例从 SDK 导入到 CCS 后，我只将链接器选项从--ram_model 更改为--rom_model，而不做任何其他修改。

此致，

月米勒

大家好，Moonil，

如果不使用 CCS，则使用 uart_uniflash.py 将使用“--ram_model”构建的二进制文件刷新到目标，并且目标为“热”重置，这种情况如何？ 我想“ 上一次跑步的值” 也可能会发生同样的情况。 您是否也能澄清此案例？

这个问题是关于产品的发行版(包括“热重置” )是否可以使用“--ram_model”构建，以及是否需要在“.sysmem”上实施其他初始化。

首先，当您使用 CCS 加载代码时，.data 部分将通过加载时间(RAM 型号)或.cinit 代码(ROM 型号)进行初始化，因此，如果重新启动 RAM 型号内置代码，将出现问题。 如果您使用 ROM 型号的内置代码，则重新启动对您有效。

在 ROM 启动情况下，“热重置”将触发 ROM 启动，而 ROM 启动 将从 OSPI 闪存加载 SBL_OPSI，它将从闪存加载应用程序代码。 在这种情况下，ROM 模型和 RAM 模型构建的应用程序代码都应该有效。 如果暂停应用程序代码并重新启动(只需将 PC 设置为0)，则 ROM 模型构建的应用程序代码应正常工作，而 RAM 构建的应用程序代码将不会运行。

此致，

明

您好，Ming，

我对您的 ROM 和 RAM 模型的理解  

1. 在 CCS 中使用“重新启动”时，建议使用 ROM_MODEL。
2. ROM_MODEL 和 RAM_MODEL 可用于“热重置”。

因此 ，在这两种情况下，ROM_MODEL 通常都是安全的。

因此，对于使用 ROM_MODEL，我认为我前面关于 MPU_INIT HOOK 函数的问题应该得到澄清。 请分享您对这个问题的看法：“调用 MPU_INIT HOOK 函数之前，未初始化全局变量。 它会导致 MPU 初始化不正确或有问题"。

此致，

月米勒

大家好，Moonil，

正如乔治和我之前所说的，ROM 模型和 RAM 模型之间的唯一区别是“运行时自动初始化变量”(ROM 模型的.Cinit 部分)。 每次重新启动时，它都会自动初始化变量。 在 RAM 模型中，变量仅在加载时间/引导时初始化，因此重新启动不会重新初始化变量。  

“调用 MPU_init hook 函数之前，未初始化全局变量。 它会导致 MPU 初始化错误或垃圾初始化错误。”

此致，

明

您好，Ming，  

感谢您的再次解释。

[引用 userid="15702" url="~/support/icros/arm-based 微控制器-组/基于 ARM 的微控制器/f/基于 ARM 的微控制器- forum/1074597/am2432-do-we-need -使用需要- ram_model-option-as an - initialization-mode-inlinker -forum-8339904_runruntime function -vot-enoid 在未初始化前调用全局环境变量 MP39904"39494"。 它会导致 MPU 初始化错误或垃圾初始化错误。”正确无误。

您的意思是 ROM 型号在 MPU 初始化方面存在问题吗？ 我现在只有一个选择，就是 RAM 模型吗？ 如果我仍有误解，请再次更正。

此致，

月米勒

大家好，Moonil，

我对 RAM 和 ROM 模型的变量初始化做了更多的调查。 以下是我找到的内容：

RAM 和 ROM 型号均使用以下代码：

_c_int00 (PC=0x0)                              BOOT_armv7r_ASM.S
  __MPU_INIT                                  TI_DPL_CONFIG.c.
  _SYSTEM_PRE_INIT
  __TI_auto_init_nonbinit_nopinit
  主要()

关键区别在于 __TI_auto_init_nonbinit_nopinit。 当使用 ROM 模型时，它会初始化全局变量。 使用 RAM 模型时，它不执行任何操作。 可以看到，全局变量初始化是在__MPU_init 之后完成的，但在 main()之前完成的；

总之，ROM 型号可以安全地进行“热重置(系统重置)”和“重新启动(CPU 重置)”，但 RAM 型号只能安全地进行“热重置”。

此致，

明  

您好，Ming，

我追踪了相同的内容，并将 CCS 屏幕捕获附加到了这个讨论主题中。 您必须检查 ROM 模型__MPU_init 中使用的全局值。

请参阅我以前捕获的图像“2) --rom_model ： ”和我的观点 ，“__MPU_init 不是由 任何重置类型的 ti_DPL_config.c 中的值初始化的。 它只有零值，如 您在捕获的图像中所见。 您认为它是正确的值吗？

[引用 userid="15702" url="~/support/icros/arm-based 微处理器-组/基于 ARM 的微控制器/f/arm-based 微控制器- forum/1074597/am2432-do-we-we-need -使用--ram_model-option-as an - initialization-model - linker - rereset - restart-us-us- restart-"3989[在系统运行时和重新启动时环境中进行“热重启”(只能在“热重启)，且在“系统”398939中进行复位[以“热重启”(重启)。

我们可以说 ROM 型号还是安全的？  

此致，

月米勒

大家好，Moonil，

你是对的。 我错过了 ROM 型号的“热重置”案例。gMpuConfig 最初被设置为0，然后被  __TI_auto_init_nonbinit_nopinit 设置为正确的值。 这将导致__MPU_init 的设置不正确。

“__TI_auto_init 引信后_MPU_init 函数应该调用”是一个逻辑解决方案，但我不确定 __TI_auto_init 引信在__MPU_init (它设置 MPU 和高速缓存)之前是否可以正确运行。

总之，除非上述更改有效，ROM 模型将无法用于“热重置”。

此致，

明

您好，Ming，

最后，我们在同一页上。 请您与您的团队核对此信息，并共享一个补丁代码，包括您提到的变更工作？

此致，

月米勒

大家好，Moonil，

是的，我将与软件开发团队讨论修复问题，以提供修补程序代码。 同时，要快速解除阻止，您能否在  boot_armv7r_ASM.S 中进行建议的更改，并告知我们您的实验结果？  

此致，

明

您好，Ming，

正如您提到的逻辑解决方案一样，我认为我们可以如下所示对其进行更改。 这似乎在我的测试中起作用，但我仍然担心任何我不知道的缓存或性能问题。 请查看此变通办法，并让我知道您团队的完美解决方案。

此致，

月米勒

大家好，Moonil，

非常感谢您的参与。 正如评论中所建议的那样。   在__TI_auto_init 之后执行__MPU_INIT 的唯一可能的副作用是性能问题。 我猜这不会导致任何不正确的结果，而不是缓慢的执行。 我一定会与我们的软件团队讨论，希望能找到更好的解决方案。

此致，

明