[参考译文] TM4C1292NCPDT：更改固件映像可执行地址而不使用硬代码

您好、Sandra、

也许我不清楚你的问题。 您的两个映像将分配给两个地址、即0x4000和0x8400。 如果 cmd 文件未指定两个程序映像的分配位置、您将如何编译/链接这两个程序映像？

三个字：Charles、

位置独立代码。

Robert

实际上是对失效防护引导加载程序的要求

您好！

如果要从闪存执行映像、并且地址现在未知、则意味着映像地址不是固定为0x4000或0x84000、那么我能否从引导代码中获取映像地址？ 是否有任何方法可以将 此地址提取到 EEPROM 中存储的变量中并在稍后加载？

此致

Sandra

您好、Sandra、
不确定您是否正在寻找 Robert 建议的 PIC。 我没有 PIC 代码经验。 如果您正在寻找这种解决方案、我们需要咨询编译器团队、因为我甚至不确定是否支持这种解决方案。 但是、如果您只是想在 EEPROM 中存储地址0x4000和0x8400、我就不会真正看到问题。 它与您当前在 EEPROM 中有一个可决定执行哪个映像的变量时所做的操作没有太大不同。

您好！

感谢你的答复。

此致

Sandra

您好、Sandra、

这不是对您提出的问题的直接回答、而是一种解决方法。 我们以前也面临着同样的需要。

我不知道 CCS 是否可以处理这个独立于 Robert 提到的位置的事情... 但我会假定、在执行过程中、这种间接地址转换需要额外的资源。 我们决定不学习它。

因此、我们所做的是始终编译主代码以从.cmd 文件中配置的固定位置运行。 最终的固件更新实际上存储在其他位置、在启动期间、如果需要、新的固件候选项会复制到默认位置。

如果我们的目标代码为"小"(实际上、略小于 MCU 闪存大小的1/3)、闪存中始终保留三个副本：当前、恢复和候选。 如果固件大于该值、则使用相同的概念、但使用外部闪存(或必须丢弃还原版本、这种情况不太安全)。

谢谢

布鲁诺

谢谢、Bruno 的见解！

您好、Charles、
很高兴能够提供一些帮助！
管理固件更新的这一主题是一个反复出现的问题、我认为我们可以共同提出一个"完整库"来实现这一目标。 我的团队在目前不太活跃的海报路易斯·安东尼奥的帮助下、已经创建了一个相当体面和可靠的解决方案-但我们仍然可以为其添加一些功能。
您是否认为 TI 协调的某种"团队合作"可能会在以后包含在 utils 库中？
我团队的"好处"是、经验丰富的同事会提供意见、并根据 TI 的"最低质量"标准增加形式、但最终肯定会是双赢的结果。
此致
布鲁诺

您好、Bruno、
我已向您发送了一封私人邮件。

您好、Bruno、

感谢你的答复

此致
Sandra

[引用用户="Bruno Saraiva">我不知道 CCS 是否可以处理这个位置 Robert 提到过的独立问题... 但我会假定、在执行过程中、这种间接地址转换需要额外的资源。 我们决定不学习它。[/引述]

不一定。 发生的情况是、常数(const int x；而不是23)和从零偏移的函数会从不同的地址偏移。 对于某些处理器(例如"小型和小型 x86型号)、这会导致零额外开销、而对于其他处理器、这可以忽略不计。 我了解68K 处理器上使用 PIC 的原始 MAC。 请注意、ARM 指令集确实包含一个相对调用、因此我不会期望过多的额外开销(如果有的话)。

CCS 是否足够好是一个单独的问题。 IAR 可以、但显然存在一些限制。

[引用 user="Bruno Saraiva">Hence、我们所做的是始终编译主代码、以便从.cmd 文件中配置的固定位置运行。 最终的固件更新实际上存储在其他位置、在启动期间、如果需要、新的固件候选项会复制到默认位置。

如果启动时的副本开销是可以接受的，则此操作将起作用。

如果不是、则 IE 的要求是

• 启动时不会产生额外开销
• 必须始终至少测试一个有效的使用二进制文件才能始终运行
  • 加载新的二进制文件后、必须可以回滚到以前工作的二进制文件(将新的二进制文件标记为"坏")
  • 新的二进制文件优先覆盖标记为不工作的二进制文件、否则用户会标记要覆盖的有效二进制文件
    • 这是除了检查二进制文件是否完整、准确以及是否来自可靠的源文件之外、这显然应该将新二进制文件标记为无效。

在这种情况下、另一种方法是将二进制文件发送到两个或更多不同的位置、并仅下载所选位置的二进制文件。 更多的链接和位置工作以及更大的分发文件、但其行为与位置无关代码。

Robert