2400736_zh-CN

是

S32K344 AB-Swap 在 HSE_ActivatePassiveBlock 后自动启动失败；固件仅可通过 J-Link Sta 启动

平台：S32K344，采用 AB 互换方案。主动模块和被动模块分别存储不同的固件镜像。观察：执行 HSE_ActivatePassiveBlock() 交换活动/被动分区后，完全断电重启不会触发固件自动启动。只有连接 J-Link 并通过调试器触发启动应用程序时，固件才能成功执行。请问有人能解释一下根本原因并提供建议的解决方案吗？

Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

嗨@HQZ

您确定被动分区中存在有效镜像吗？如果在启动目标后不RESET它，而是将调试器连接到正在运行的目标上，你会观察到什么现象？设备是否进入JTAG恢复模式？或者，您也可以直接通过调试器重置设备，然后检查它是否到达了应用程序的入口点。

如果设备在地址 0x2040012C 处陷入无限循环，则表明它已进入 JTAG 恢复模式。这也可能表明 IVT 配置或 IVT 完整性存在问题。

另外，被动分区中的映像是否链接到活动分区地址空间运行，即从 0x00400000 开始运行？

最后，你们是否启用了安全启动？

此致，

Lukas

Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

你好@lukaszadrapa

平台：S32K344，AB-Swap架构。独立固件镜像分别存储在主动块和被动块中。HSE安全启动已禁用。问题描述：调用HSE_ActivatePassiveBlock()完成主动/被动分区切换后，设备在断电后RESET无法自动启动目标固件。但是，如果将J-Link调试器连接到芯片，并在调试器软件中点击“启动应用程序”，则切换后的固件可以正常运行。补充背景：固件同时存在于分区A和分区B中。两个镜像之间的唯一区别是LED闪烁频率。分区A固件的链接起始地址为0x400000，而分区B固件的链接起始地址为0x600000。调用HSE_ActivatePassiveBlock()并RESET后，我使用J-Link转储了闪存内容。分区A和分区B的内容已物理交换，证实HSE_ActivatePassiveBlock()已生效。问题：1. 此行为的根本原因是什么？为什么冷启动和调试器触发的“启动应用程序”的行为不同？2. AB分区交换后，有哪些可行的解决方案可以解决自动启动失败的问题？感谢您的支持。

Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

嗨@HQZ

“分区 B 固件链接起始地址为 0x600000”——这就是问题所在。两个映像必须链接才能使用活动分区地址 – 0x400000。应用程序始终在活动分区上运行，而不是在被动分区上运行。

解决方法——对两个项目使用同一个链接器文件。

它之所以能与你的调试器配合使用，是因为调试器会“手动”将程序计数器设置为入口点地址，该地址位于 elf 文件中。

此致，

Lukas

Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

你好@lukaszadrapa

我已按照之前的建议尝试了 AB 分区交换，但问题仍然存在。
使用的 HSE 固件版本为 s32k344_hse_fw_1.5.0_2.40。

用于验证 AB 交换的测试设置：
具有基于应用程序的自我更新的单链接器脚本。该应用程序负责将新的固件映像编程到被动分区中。
链接器脚本：只使用一个链接器脚本，固件起始地址始终设置为 0x00400000。

工作流程：
1.在分区 A（逻辑地址 0x00400000）中运行的应用程序通过 CAN 接收新固件。A分区和B分区固件之间的唯一区别在于LED闪烁频率。
2. 该应用程序将新固件直接编程到被动分区的物理地址（0x00600000）中。
3.编程完成后，调用 HSE_ActivatePassiveBlock() 服务。
4. 然后 RESET 芯片。

观察：
固件RESET后无法运行。但是，当连接 J-Link 并从调试器触发“启动应用程序”时，分区 B 中的固件可以正确执行。

还有哪些其他根本原因会导致分区交换失败，相应的解决方法是什么？

问候

Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

很抱歉回复晚了。

以下是一些常见问题：

运行 HSE_ActivatePassiveBlock() 并重置设备后，大约需要 1 秒 HSE 才能准备好接受新的服务请求。这是因为 HSE 会将 HSE 固件备份到被动分区。操作完成后，FSR 寄存器中的 HSE_STATUS_INIT_OK 标志将被置位。所以，在 HSE 完成之前，无法使用它。有时这就是麻烦的根源。

固件版本 0.2.55.0 及更高版本已对此进行了优化，并且仅当固件更新时才会将其复制到被动分区。如果结果仍然相同，HSE 将跳过此操作，交换速度会快得多。

然后我建议阅读 HSE 固件参考手册修订版中的描述。2.7 节：

“14.6.5同步 HSE 和应用核心之间的闪存读/写访问：

https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7

表 149、150 和 151 中提供了典型场景的详细信息。

就您的情况而言：当 HSE 将自身备份到被动分区时，无法访问闪存块 3，因为 HSE 在该块上执行闪存操作。

另外，您不能对块 1 执行刷写操作，因为 HSE 固件正在该块上运行。

还有一点，如果 HSE 正在运行，则无法更改 HSE_CLK。重置后，HSE 运行约 1 秒，此时可能会出现问题。

更改 HSE_CLOCK 时，HSE 必须处于IDLE状态。HSE 运行时无法更改时钟。这可能会导致不可预测的行为。S32K3 参考手册中明确提到了这一点：

“在配置 HSE_CLK 之前，必须等待 SBAF 通过读取 HSE CPU 的核心状态寄存器 (PRTN0_CORE2_STAT) 进入 WFI 状态。”

使用旧版本的 RTD 驱动程序时可能会出现问题，因为这些驱动程序不会检查上述状态寄存器。

该检查已在 RTD 版本 5.0.0 及更高版本中实施。如果您使用的是旧版本，则需要在时钟初始化之前轮询 WFI。所以，这可能也是它失败的原因。

回复： S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

你好，兄弟

我也遇到了同样的问题。请问您是如何解决这个问题的？

回复： S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link

你好，
很抱歉回复晚了——我刚看到您的消息。问题是否已解决，还是您仍然需要帮助？