我们正在尝试在定制 PCB 上对 C6657执行 UART 模式引导。
根据 TI 文献中的指导、我们合成了一个包含二进制引导表(从 hex6x 实用程序的.hex 输出转换)的文件、该文件打包成数据包以满足 Xmodem 标准。 当我们在上电复位后启动引导加载时、我们的整个引导文件会成功地与预期的来自6657数据包的 ACK 进行传输。 但是、这之后引导映像似乎没有运行、当我们在引导后通过 JTAG 连接到处理器时、我们看不到 C6657的 SRAM 区域(L2和 MSMC)中安装了代码或 CINIT 段的任何证据。
下面是我们项目的二进制、xmodem 打包引导表和范围跟踪、用于验证其到 C6657的确切传输。
您能否查看详细信息并向我们建议错误的操作？
我们已重新排序段说明符和段数据的字节序(32位级别)。 但会发生相同的结果。 我们在 TI 文献中找不到任何进一步的信息来说明问题是什么。
又花了一天的时间进行实验。
1) 1) 您发送给我用于6657 UART 引导的.bin 映像使用 TeraTerm 正确引导到我的 EVM 中。
为此、需要使用下图所示的 EVM 开关配置：
此处的关键课程： SW3：1： 针对大端字节序设置。
调查结果：
在任何情况下、如果开关3：1处于小端序关闭位置、C6657 ROM 引导加载程序都不会将任何数据复制到任何 C6657存储器中。 在 XMODEM 交换时、引导加载程序似乎在完整的二进制引导表中读取、但仅丢弃数据。 ROM B/L 最终会"卡在"由本帖子中更高提到的 ROM BL 地址位置封装的环路中。
我生成的任何引导映像都是如此、其中引导映像 TI 提供了我、并生成了一个小的手动编码(即非常简单)二进制引导表。 诸如反转段头的字节排序等排列没有任何不同。 确定性行为：
上电端序= BIG (SW3：1打开)- XMODEM 传输后、始终在 C6657存储器中找到引导映像数据(即使映像中的端序错误也是如此)
小尺寸(SW3：1关闭) C6657存储器在 XMODEM 传输后"未触摸"、RBL 仍在循环中执行。
假设：
要使用 UART 引导模式、必须将芯片配置为大端字节序。
这意味着引导的固件要正常工作、必须为大端序 ALU 操作编译它。
支持测试：
我们在 CCSv7的大端字节序设置中重建了引导测试程序。
为 hex6x 提供了命令行：
hex6x -boot -a -e=_c_int00 -order=M -memwidth=32 -romwidth=32 -oBootTest_A.hex -mapBootTest_A.map BootTest_A.out
转换为二进制：
使用在 VS2015C++编译器中修改的 BConvert64实用程序仅输出二进制文件、并应用 -be 标志。
bConvert64 BootTest_A.hex BootTest_A.dat -be //修改的 BConvert64。 写入二进制文件、而不是 ASCII 文件
UART 发送到6657：
Tera Term XMODEM 传输。 通过与 XDS100 mini USB 关联的 USB 虚拟通信将.dat 文件传输到 EVM。
已验证：
已连接调试、无程序加载或 GEL 加载。
一旦我们重新接线以将 GPIO[0] ENDIAN 设置为大电平、我确信这在我们的定制板上也能正常工作。
结论：
如果不能查看 T.I.的 ROM B/L 的源代码、我很有信心上述断言是正确的。
