您好：

看起来您修改了“default_sbl_null.cfg“文件、因为默认文件会发送 sbl_UART_UNIFLASH 和 sbl_NULL 映像。 请尝试使用未修改的 cfg 文件进行刷写。

https://github.com/TexasInstruments/mcupsdk-core/blob/next/tools/boot/sbl_prebuilt/am64x-evm/default_sbl_null.cfg

您好、

对于我们的应用、我们计划使用 OSPI、但我们没有组装 DDR、因此我们尝试修改 SBL ospi。 请指导后续步骤。

我假设您使用的是定制板、请确认是否不是这样、如果您在电路板上使用定制 OSPI、则需要按照本指南在 UART UNIFLASH： https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/12_00_00_27/exports/docs/api_guide_am64x/CUSTOM_FLASH_SUPPORT_GUIDE.html 中添加对定制闪存器件的支持 

默认 UNIFLASH 使用放置在 DDR 中的缓冲器接收映像、然后稍后将其复制到闪存、因为您没有 DDR、您需要在 SBL UART UNIFLASH 示例中进行一些更改、并将其从 DDR 移动到 MSRAM  、您可以按照此处提到的步骤操作：AM2431：AM2431–UART Uniflash 到 OSPI FS 在定制电路板上使用 HS-SBL 进行刷写故障  

此致、
会面。

谢谢会见。 一个快速查询、我们使用的 OSPI 器件型号与评估板相同。 我们是否仍需要执行第一步更改？  

感谢您的支持。

你好 Sarita Jangid ,

[引述 userid=“698194“ url=“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1643076/am6421-programming-custom-board-with-am6421bsefhaalvr-using-only-r5f-core/6334808 ]我们使用的 OSPI 器件型号与评估板的 OSPI 器件型号相同。 我们是否仍需要执行第一步更改？  [/报价]

如果使用与 EVM 完全相同的 OSPI 闪存器件型号、并且闪存以相同的方式连接、则无需添加自定义闪存支持或修改 UART Uniflash 闪存驱动程序。

在这种情况下、您可以跳过自定义闪存支持指南中的步骤、仅关注无 DDR 系统所需的 SBL UART Uniflash 缓冲区更改。

 回复：AM2431：AM2431–FS 定制板上使用 HS-SBL 时 UART Uniflash 刷写故障 

谢谢、

JOMY

感谢您发送编修。 我们遵循了您建议的步骤、下面是供您参考的配置捕捉。  

但我们得到的结果是一样的。 卡在第二步。

此外、我们还尝试使用零 SBL。 我们收到 A53 内核 1 的错误、我们是否可以从 SysConfig 中将其分解？ 友好的导游。 谢谢你。  

我们尝试在定制 AM6421 电路板上刷写 OSPI NOR 闪存。

处理器：
AM6421BSEFHALVR

OSPI 闪存：
S28HS512TGABHM010

问题描述：
我们 uart_uniflash.py 将与一起使用 default_sbl_null.cfg。 刷写过程会卡在第二条命令上、速度为 0%。

作为一种权 sbl_null.Release.hs_fs.tiimage CCCC 变措施、我们尝试在 UART 终端上接收到连续字符后、使用 XMODEM 协议手动从 Tera Term 发送图像。

有一次、我们成功发送了 sbl_null.Release.hs_fs.tiimage 一次、但无法再次发送、如论坛主题的闪存诊断设置过程中所述。

此外、我们还通过注释掉其他内核的引导来修改引导流程、因为在 A53 引导期间引导过程失败。 以下各节已注释掉：

//status = Bootloader_bootCpu(bootHandle, &bootImageInfo.cpuInfo[CSL_CORE_ID_M4FSS0_0]);

//status = Bootloader_bootCpu(bootHandle, &bootImageInfo.cpuInfo[CSL_CORE_ID_A53SS0_0]);

//status = Bootloader_bootCpu(bootHandle, &bootImageInfo.cpuInfo[CSL_CORE_ID_A53SS0_1]);

进行此修改后、我们能够使用闪存诊断工程通过 CCS 进入调试模式：

ospi_flash_diag_am64x-evm_r5fss0-0_nortos_ti-arm-clang

但是、运行诊断应用程序后、无法正确检测/读取 OSPI 闪存制造商 ID 和器件 ID。

使用以下 UART 输出发出第一条命令时、诊断测试会立即失败：

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Starting ...

MAIN_Cortex_R5_0_0: Some tests have failed!!

我们希望就以下几点提供指导：

1. AM64x SDK OSPI 驱动程序是否正式支持 S28HS512TGABHM010？
2. 对于此闪存器件、是否需要对此闪存器件的闪存配置或 PHY 设置进行任何更改？
3. 此故障是否表示存在以下问题：
   • OSPI 时钟配置
   • Pinmux
   • Phy 调优
   • 复位序列
   • 闪存协议模式（八进制 SDR/DDR）
4. 在运行完整诊断测试之前、是否有建议的方法来验证与该闪存的低级通信？
5. 为什么会 uart_uniflash.py 卡在第二个命令的 0%？

任何关于调试该问题的建议都将非常有帮助。

尊敬的 Sarita：

1.是的、AM64x MCU+ SDK 正式支持 S28HS512TGABHM010 Serial NOR OSPI Flash 器件、 用户指南中还提供了有关支持的闪存器件的信息。

2.不可以、SysConfig 中存在的闪存的默认配置应该起作用。 如果使用不同的频率、闪存配置中的唯一更改是读取周期和命令虚拟周期。 有关延迟/虚拟周期的信息、请参阅闪存数据表。

3 和 4。 是、建议 使用以下命令运行 OSPI 闪存诊断：

python uart_bootloader.py -p COMX -b sbl_prebuilt\am64x-evm\sbl_uart.release.hs_fs.tiimage -f "path to ospi flash diagnostic image"

5.可能是闪存配置问题、您可以尝试使用上述命令运行 OSPI 闪存诊断并共享日志吗？

此致、

Aryamaan Chaurasia

大家好、我是 Sourav Singh。

我们使用编译的应用程序映像本地路径从 CMD 执行 UART 引导命令。

使用的命令：
python uart_bootloader.py -p COM3 -b sbl_prebuilt\am64x-evm\sbl_uart.release.hs_fs.tiimage -f "<appimage_path>"

观察到的输出：

• UART 引导加载程序sbl_uart.release.hs_fs.tiimage() 已成功发送。

• 应用程序映像ospi_flash_diag...appimage.hs_fs() 也已成功传输。

• 传输完成而不会出现任何通信中断。

但是、应用程序传输完成后、观察到的最终状态为：

[STATUS] ERROR: Application load FAILED !!!

这表明通过 UART 进行的映像传输成功完成、但应用程序在目标上的加载/引导阶段失败。

此外、当执行同一个工程时：
ospi_flash_diag_am64x-evm_r5fss0-0_nortos_ti-arm-clang

直接在 CCS 调试模式下执行（通过 xmodem 通过 Teraterm 加载 sbl_null.Release.hs_fs.tiimage 后）、会观察到以下输出：

MAIN_Cortex_R5_0_0: [OSPI Flash Diagnostic Test] Starting ...

MAIN_Cortex_R5_0_0: Some tests have failed!!

进一步调试表明在制造商/器件 ID 自行读取期间发生故障、其中返回的状态为 -1 以下 API：

status = OSPI_norFlashReadId(ospiHandle, &manfId, &deviceId);

目前、除了执行上述命令和验证生成的映像路径之外、我们方面没有执行任何其他更改或调试步骤。

请告知我们、是否有在引导、OSPI 配置或映像生成过程中可能错过的任何其他步骤/配置。

尊敬的 Sourav：

您能否请检查与闪存的硬件连接、并确保在使用定制电路板后 OSPI 线路已正确连接。

OSPI 闪存诊断应能正常工作、因为它以最基本的协议 (1S-1S-1S) 运行、并且应该正确地获取器件 ID 和制造商 ID。 您能否请咨询您的硬件团队以获取定制电路板的原理图审阅、并确保其与此 常见问题解答一致。

此致、

Aryamaan Chaurasia

您好、

[引述 userid=“686310“ url=“~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1643076/am6421-programming-custom-board-with-am6421bsefhaalvr-using-only-r5f-core/6335770

在这种情况下、您可以跳过自定义闪存支持指南中的步骤、仅关注无 DDR 系统所需的 SBL UART Uniflash 缓冲区更改。

 回复：AM2431：AM2431–FS 定制板上使用 HS-SBL 时 UART Uniflash 刷写故障 

[/报价]

按照上述回复更改 UART Uniflash 示例后、您是否正确地重建了示例？

此外、您是否还可以共享 UART Uniflash 示例的 example.syscfg 文件？ 我想检查该示例的闪存和 OSPI 配置。

此致、

Aryamaan Chaurasia

尊敬的 Aryamaan：

是的、我们在进行建议的更改后正确重建 UART Uniflash 示例、并在测试之前生成了更新的二进制文件。

我们还共享该 example.syscfg 文件以用于查看闪存和 OSPI 配置。

e2e.ti.com/.../7411.example.zip

您好、

您的定制电路板是否具有 eMMC？

此致、

会面。

不可以、我们仅使用 R50 内核和 OSPI 引导模式、支持 UART 回退。 未组装/未使用 DDR 和 eMMC。

引导模式：-

SW3 (0→7)：1 1 0 0 1 1 0

SW2 (8→15)：0 1 1 1 0 0 0 0

您好！
从中删除 MMCSD/eMMC 实例后、UART uniflash 命令流现在正在运行 example.syscfg。

但是、在尝试使用 Uniflash GUI 与配置的 XDS200 进行连接时、我们会收到以下错误：

Run failed...
File Loader: Memory write failed: Timed out waiting for target to halt while executing am243x_alv_flasher.out

另外,当我们连接到 UART 终端并按重置时,我们会连续接收 "CCCC" 而不是引导 sbl_null。

您能否建议在 Uniflash GUI 模式下导致此问题的原因？

您好、

最好是您成功刷写了 SBL NULL。 您能否请切换到 OSPI 引导模式以运行 SBL NULL

您能否建议在 Uniflash GUI 模式下导致此问题的原因？

您还能检查一下 tiboot3.bin 为 AM6421 构建的吗

谢谢、

JOMY

感谢你的评分 即、我们使用以下引导模式配置  

引导模式：-

SW3 (0→7)：1 1 0 0 1 1 0

SW2 (8→15)：0 1 1 1 0 0 0 0。

因此、支持 OSPI 引导模式和 UART 回退模式。

即使我们对 UART uniflash 使用 tiboot3.bon、输出也是相同的。  

您能否建议在 Uniflash GUI 模式下导致此问题的原因？

如果使用 UART UNIFLASH 刷写成功、您能告诉我为什么要使用 Uniflash GUI 再次刷写二进制文件？

另外、当我们连接到 UART 终端并按“重置“时、我们将连续收到 "CCCC" 而不是启动 sbl_null。

这表明 ROM 无法从 OSPI 引导 SBL 二进制文件、因此它切换到备用引导模式。 您能否检查一下您是否能够通过 UART 引导 SBL NULL？ 您可以将 sbl_null 发送为引导加载程序二进制文件 、而不是发送 sbl_uart：https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/12_00_00_27/exports/docs/api_guide_am64x/TOOLS_BOOT.html#UART_BOOTLOADER_PYTHON_SCRIPT 

尊敬的会议：

我们可以 sbl_null.release.hs_fs.tiimage 使用 TeraTerm 手动加载 XMODEM、并能在 RAM 中正确引导。 但是、 uart_uniflash.py 使用的刷写 default_sbl_null.cfg 仍然失败。

我们还 uart_bootloader.py 使用进行了测试 sbl_uart.release.hs_fs.tiimage、其中引导加载程序和应用程序传输都成功完成、但结束于：

[STATUS] ERROR: Application load FAILED !!!

您好、

由于存在 ROM 引导故障、您能否参考 xSPI 调试指南的引导故障一节？

同时、请给我们更多时间来调查这个问题。

此致、

Aryamaan