[参考译文] SBL-AM263PX：版本 11 中的 MCU-PLUS-SDK 问题

1) sbl_ospi 文件夹为空。 这个示例是否放弃了其他示例？ 奇怪的是文件夹仍然存在、但为空。

您好 Nathan、

这与我们的讨论是一致的、我曾提到 rprc (.appimage) 映像格式支持 (sbl, build infrar) 将被删除。

请使用 sbl_OSPI_mcelf 进行进一步测试。

我想您已经在使用它了。

2) 并非所有 SBL OSPI 示例都分配了其 OSPI 引脚。 查看 sbl_ospi_fastboot/am263px-cc example.syscfg、它可以清楚地为 OSPI 上的所有引脚设置为 advisestSolution（在 syscfg 中解析为“any"）“）。

我会得到这个修复,我也有点震惊,如果这被团队错过了,为此道歉。

3) sbl_ospi_morple_elf/am263px-cc example.syscfg 几乎分配了所有 ospi 引脚。 RESET_OUT0 仍配置为 EPWM11_B 的建议解决方案 构建时、此工程（以及之前 SDK 10_02_00_15 中的 sbl_ospi 和 SDK 11_00_00_19 sbl_ospi_fastbook/am263px-cc）reset_OUT0 引脚解析为 EPWM11_B（在 pinmux.csv 以及 ti_00_config.c 中看到）。根据原理图、我们实际上已通过 LED1_fastbook/am263px-cc  用户开发并已验证此引脚。 在这个项目中是一个非常具体的 flashFixUpOspiBoot() 函数、它调用 OSPI_setResetPinStatus () 函数来将引脚设置为高电平、然后设置为低电平。 尽管很难判断这些复位函数是否实际使用我们的控制卡版本调用（它们似乎被跳过）。

这需要根据您的电路板进行调整。 我们对 SDK 中的闪存复位 (flashfixUp API) 有建议、应由您确保在电路板级别和应用级别存在适当的闪存复位机制。

根据我们发现的一个硬件问题、对复位机制进行了修改。

在最新的 SDK 中、似乎仍然没有真正有效的示例解决方案。

您好 Nathan、

如讨论中所述、尚未得出结论认为问题出在 SBL SDK 上、因为以类似方式实现问题的其他客户尚未报告此类问题。 我会建议您的安装中的第一个根导致它崩溃并进入失败。

您是否可以共享您的 SBL 工程、这样我也可以观察到您看到的稳定性问题。

当前的问题是、我们在某些时候没有切换到 4 字节模式。 我有一个控制卡,工作正常 80%的时间,和另一个控制卡（相同的版本）从不启动,即使两个运行完全相同的映像从启动。 在我发表具体内容之前、我想明确指出、这只是我们最近面临的一个问题、因为我们将继续面对看似随机的问题。

我们可以看到、当电路板按预期启动时、我们能够连接到 R5_0 并读取存储器区域 0x600E0000、具体请参阅：

在无法正确引导的板上、当我们查看存储器区域 0x600E0000 时、我们可以清楚地看到只得到 4 个字节中的 3 个：

我们已经验证了所有开关设置。 我们已经使用 UniFlash 来验证地址 0x600E0000 中的内容在编程后是否按预期显示（两个控制卡上都存在所有 4 个字节）。

当我将 LOOP_FOREVER 函数添加到 SBL 中、然后在 CCS 中进行连接以逐步完成故障控制卡上的引导时、我会看到以下内容：

请注意、为了稳定运行、我们已缓慢回滚对 TI 示例代码的修改。 本文所示主代码中调用的函数尚未从 SDK 10_02_00_15 的 sbl_ospi 示例中修改。

您好 Nathan、

我想澄清的一点是、

您是否注意刷写 PHY 攻击向量、如果您以最大频率运行 OSPI、这一点非常重要。 因此可能会导致一些 OSPI 不稳定？

项目文件已上传到 TI Drive、因此您可以随时仔细检查设置。 但是、我可以看到、SBL 工程中的 PHY 配置与 SDK 10_02_00_15 中 sbl_ospi 示例中的 PHY 配置完全相同。

一个非常有趣的观察。 在使用持续发生故障的控制卡时、我根据 sbl_ospi 示例加载了未更改的构建并启用了 LOOP_FOREVER、并浏览主函数 、直到我到达 Bootloader_profileAddProfilePoint（“Board_driversOpen")“）调用。 在这种情况下、我没有得到任何表明 PHY 未能初始化的迹象（如上文该线程中所示）。

之后、我将我们的定制 SBL 重新加载到同一控制卡上、并逐步执行代码到代码中的同一点。 这次没有收到有关无法正确启用 PHY 的错误。 现在我还可以正确地看到存储器地址 0x600E0000 的内容（所有 4 个字节而不是 3 个字节）。  

因此、我认为可能存在 PHY 未正确启动的问题。 但是、我无法确定 SysConfig 或自定义代码中 PHY 从我们的自定义 SBL 到 sbl_ospi 示例之间存在差异的位置。

是的、因为您需要至少在 0x80000 偏移处对攻击向量进行一次编程、只要存在且不被擦除、PHY 调优也将按预期与其他程序配合使用。

您是否能够向我提供有关“在 0x80000 偏移处对攻击向量进行编程“的更多详细信息？ 技术参考手册或过程中是否有内容详细说明了这是什么以及如何正确操作？

什么是 PHY 调优和攻击向量： https://www.ti.com/lit/pdf/spract2

此处提供更多详情： e2e.ti.com/.../faq-am62x-am62ax-am62px-am62d-q1-am64x-am243x-ospi-phy-tuning-algorithm

我们已经能够确定示例 ospi 项目正在检测不正确的 phy 调优数据并将其修复。  我们还能够确定我们的版本检测到不正确的 phy 调优数据、但无法纠正。 具体来说,在 flash_nor_ospi.c 文件的 Flash_norOspiOpen () 函数中,我们的版本能够成功执行 Flash_norOspiEraseSector () 函数（我们已经验证错误的数据被写入 0xFFFFFFFF ）,但随后在 Flash_norOspiWrite () 函数的下一行失败。 遗憾的是、我们无法在 SysConfig 或两个工程之间不同的导致这种行为的代码序列本身中识别出任何内容。 我甚至在运行时向下驱动到 OSPI_LLD_writeIndirect () 函数,并验证此函数中使用的所有变量在 2 个项目之间是相同的。 我们遇到了这样的情况、在经过几天的专门工作和分析之后、我们似乎无法摆脱这种情况。

您好 Nathan、

让我回顾一下您分享的代码、我将尝试在下周初重新使用它。

Nathan 的问题是什么？