[参考译文] AM2434：将文件传输到闪存后、PHY 启用偶尔失败

您好、Owen Young、

请提供以下信息。

1.您正在测试的工业通信 SDK 版本 (ind_comms_sdk_am243x_09_xx_xx_xx)。

2.您已根据应用调整的 EtherCAT 子设备设备配置文件示例。

[ C：\ti\ind_comms_sdk_am243x_09_xx_xx_xx\examples\industrial_comms\EtherCAT_slave_demo\device_profiles\]。

3.您是测试自己的 foe 功能实现还是使用 SDK 默认  foe 功能实现进行测试？

4、您要通过 foe 传输的文件大小是多少? 您在闪存中写入此文件的偏移量是多少？ 闪存偏移对于写入每个文件是固定的还是对于下一次文件下载而言是递增的行为？

5.您是否尝试过 foe 上传来检索您通过 foe 下载下载的文件,并验证两个文件是否相同?

6.您是否试图在第 18 次文件下载后多次传输预定义长度相同的文件或具有不同长度和错误的不同文件? 第 18 个文件的闪存偏移量和长度是多少？  

7.您正在使用哪个 EtherCAT 主设备进行测试？ TwinCAT、CTT 工具还是其他主器件？

此致、

1.9.1.0.3

2.我们没有使用 TI 子器件 EtherCAT 协议栈。 这是 Beckhoff 堆栈。  

3.我们有自己的 foe 功能实现。  

4、传输 4 个文件 — 一个 675kb 文件、一个 300kb 文件和两个 1KB 文件。 根据我的调试结果、它会将文件写入 44302336 到 45516800 的地址范围、并偶尔进行写入  51388416.然而,在重新启动时,有时文件被写入其他地址,如~26072064。 文件系统（FoE 复制的位置）的地址范围为 3407872 至  66846719。文件系统的起始地址和结束地址在重新引导期间保持一致。 在设置文件系统的地址限制时、我们设置了结束地址、以便将最后一个块用于上述攻击向量。  

5.是的,我已经尝试过这个。 虽然我今天没有时间检查每一个文件,我检查的一个（ 300kb 文件）是完全相同的一个我转移过。

6.我们所做的是 为固件升级传输 4 个文件。 现在没有进行固件升级、仅传输 FoE 文件。 我设置了一个自动测试以执行以下操作：1) 将 4 个文件传输到子设备、环中总共有 5 个节点 2) 对环和主设备进行下电上电、以确保仍然检测到所有 5 个节点。 如果没有、请退出自动测试。 抱歉、我们没有传输 18 个文件、帖子中不清楚。 第 18 次重新启动是一个转折点不是一个保证,这只是我第一次自动执行 FAE +重新启动过程所发生的事情。  我需要执行更多测试来确认或否认这一点。  

7.我们使用的是内部开发的主设备,它运行 etherlabs 堆栈。  

我将在周末离开我的自动测试、以确保我们不会覆盖任何敏感文件地址（前两个块和最后一个块）。  

您好、Owen Young、

请 升级到 可用于 AM243x 的最新版本 ind-comms-SDK、然后再次测试。

 此致、

尊敬的 Owen：

4. 我们正在传输 4 个文件 — 一个 675kb 文件、一个 300kb 文件和两个 1KB 文件。 根据我的调试结果、它会将文件写入 44302336 到 45516800 的地址范围、并偶尔进行写入  51388416.然而,在重新启动时,有时文件被写入其他地址,如~26072064。 文件系统（FoE 复制的位置）的地址范围为 3407872 至  66846719。文件系统的起始地址和结束地址在重新引导期间保持一致。 在设置文件系统的地址限制时、我们设置了结束地址、以便将最后一个块用于上述攻击向量。  [/报价]

你能做 Flash_read () 在 Flash_write () 之后读回闪存内容并验证内容是否匹配,并且没有发生数据损坏。 这将有助于排除可能导致启动失败的数据损坏的可能性。

目前、在 EtherCAT Beckhoff 演示（直至 SDK v11.00）中、FoE 采用了一种逐块方法、其中每个闪存块会单独擦除、写入到、然后进程移动到下一个块。 这意味着、对于适用闪存区域中的每个块、我们执行了一个擦除操作、然后立即执行一个写入操作、然后再继续执行下一个块。

展望未来（即将发布的版本）、我们更新的 FoE 实施将采用两个阶段的方法：

1. 初始阶段：一次擦除所有适用的闪存块。
2. 写入相位：然后按顺序将数据写入每个块。

您可以在代码库中尝试这种两相方法、然后查看问题是否仍然存在。 我们已在 AM261x 工业通信 SDK v10.02 中实现了此目的。

此致、
Aaron

我能够获得最新的工业通信 SDK 和构建的最新 MCU PLUS SDK（MCU Plus 11.1.0.17 和 ind communs 11.0.0.8 构建在一起）、但我仍然会收到完全相同的错误消息。 非常奇怪的是、Flash_norOspiOpen (1269) 的行号完全相同、尽管事实上在 MCU 加上 11.1.0.17 后、行号为 1329、而在工业通信 SDK 中。 我们使用 sbl_JTAG_uniflash_am243x-lp_r5fss0-0_nortos 刷写电路板、即使我们在加载引导加载程序和应用程序之前擦除整个闪存、也会发生这种情况。 我还缺少其他东西吗？ Board_flashOpen 在特殊位置的位置是否不受该电路板刷写程序的影响？

尊敬的 Owen：

很奇怪的是 Flash_norOspiOpen (1269) 的行号完全相同、尽管在 MCU 加上 11.1.0.17 的行号是 1329、在工业通信 SDK 中。

EtherCAT 应用程序似乎未使用 MCU+ SDK 11.01.00 中的最新库。 但是、由于您已经在 EtherCAT 工程 makefile 中处理了 MCU+ SDK 中特定于 FreeRTOS 的新库名称、因此这些行应该对齐。 为了确保对齐了编译更改、您能否确认是否正在为您的工程使用以下库？  

此外、我相信您已在 EtherCAT 工程 makefile 中的 define_common:下添加了定义“os_freertos"：“：

DEFINES_common := \
	-DSOC_AM243X \
	-DOS_FREERTOS \
	-DTIESC_APPLICATION=1 \

  有关更多详细信息、请参阅将示例从旧版本迁移到 11.01.00。

这是为了确保您已正确集成更改、并且没有遗漏任何内容。

此致、
Aaron

感谢您的帮助、Aaron。 在我们的软件生态系统中、我们使用自己的编译器重新编译 MCU Plus SDK、并将所有部分与通用库名称相适应、因此我认为库名称不是问题。  但是、我们只在 makefile 中定义了-dOS_FreeRTOS、而不是其他两个。 这会有什么不同吗？ 我是否还需要设置 TIESC_HW？

我现在似乎正在运行最新的代码、但是我们的应用程序甚至无法启动、只打印这三行：

DMSC Firmware Version 11.0.7--v11.00.07 (Fancy Rat)
DMSC Firmware revision 0xb
DMSC ABI revision 4.0

以前、我认为我们的引导加载程序文件 (sbl_ospi.release.hs_fs.tiimage) 未正确更新、但这次更新成功。 因为 DMSC 固件版本与以前不同、所以我可以判断其中有一些新内容。 这是用于打印的内容：

DMSC Firmware Version 9.2.8--v09.02.08 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

我们将为应用程序使用预编译的引导加载程序（位于 mcu_plus_sdk_am243x_11_01_00_17/tools/boot/sbl_prebuilt/am243x-lp/sbl_ospi.release.hs_fs.tiimage）  

尊敬的 Owen：

我们只有 在 makefile 中定义了-dOS_freertest、但这两者不相同。 这会有什么不同吗？ 我是否还需要设置 TIESC_HW？

 请确保在 ecat_def.h 中将 TIESC_HW 设置为 1、并将 TIESC_application 设置为 1。

我现在似乎在运行最新的代码、但是我们的应用程序甚至没有启动、只有这三行被打印：

让我在内部咨询相应的专家。

此致、
Aaron

谢谢 Aaron。 仅供参考、我能够在 am243x Launchpad 上加载此 SBL 文件而不会出现任何问题。 今天、我完全擦除了器件上的闪存、并使用 TI uniflash python 脚本来加载引导加载程序和我们的应用、结果仍然相同。  

Aaron — 我想我们弄清楚了为什么引导加载程序没有正常启动。 在 bootloader.h 中、有一个名为 bootloader_scratch_MEM_enable 的定义 、用于控制 Bootloader_verifyMulticoreImage 是否尝试从 syscfg 和 sbl_ospi main.c 示例中定义的暂存存储器区域读取。 我能够缩小引导加载程序在 Bootloader_parseMultiCoreAppImage 内的某个位置崩溃的范围（在 sbl_ospi_am243x-lp_r5fss0-0_nortos_ti-arm-clang 的 main.c 中调用每个函数后、我放置了一堆 print 语句、并在将 bootloader.c 与 SDK 中的上一个版本进行比较后看到了这个新标志。 我还在生成的 syscfg 代码中看到该标志。 没有打印错误、因此我认为发生了崩溃。 我不确定器件是否需要这个暂存区具有正确的存储器容量、因此更改了 bootloader.h 中的定义 老实说、我仍然对这段代码的实际作用感到困惑、但出于任何原因、我们的电路板配置与它不兼容。 我们的电路板现在使用 MCU plus SDK 11.1.0.17 中的新引导加载程序（由 ME 重建）运行。 我目前正在进行测试、我将告诉您新的 SDK 是否解决了我第一篇文章中所述的问题。  

Owen

Aaron、我想知道您是否能够在这个问题上获得一些帮助。 我能够完全清除我们电路板上的闪存,并重复在原始帖子中描述的测试（文件传输,重新启动,重复）。 我们收到这个消息、它至少是新 SDK 的正确行号、但我们不知道出了什么问题。  

ERROR: Flash_norOspiOpen:1329: Flash_norOspiOpen : PHY enabling failed!!! Continuing without PHY...
ERROR: Board_flashOpen:204: FLASH open failed for instance 0 !!!
ASSERT: 1.153006s: ../main.c:main:131: status == SystemP_SUCCESS failed !!!

查看源代码、它看起来像与 PHY 调优相关的操作、但我不确定我们是否需要在末端执行任何操作来提供帮助。 谢谢你。  

尊敬的 Owen：

对延误表示歉意,我可以在我结束时重现这一点 仅当您使用 JTAG UNIFLASH 刷写 SBL OSPI 时、才会观察到此问题、我正在尝试弄清楚 JTAG UNIFLASH 为什么会出现此问题、但如果您使用 UART UNIFLASH 刷写 SBL OSPI、则不会观察到此问题。

不用担心、我很感谢您的答复。 您是否说使用 JTAG Uniflash 时 LaunchPad 电路板上遇到了类似的问题？ 我对器件所使用的过程是：

使用 sbl_JTAG_uniflash_am243x-lp_r5fss0-0_nortos_ti-arm-clang 工程擦除电路板

2.使用 MCU+ SDK 中提供的 usb_dfu_uniflash.py 脚本刷写电路板。 我们的器件上有一个 USB-C 端口、用于实现此目的。  

谢谢你

满足 — 感谢您的更新。 当我们使用 DFU UNIFLASH 脚本时、我们的 cfg 文件使用此参数：

# Program the OSPI PHY tuning attack vector
--operation=flash-phy-tuning-data

因此、我认为我们正在进行闪存调优数据。

我仍然会尝试你的建议。 我将在删除这两个选项的情况下重新编译 SBL ospi 并重试。