这个问题可能对于两名 TI 工程师来说太忙了、他们在销售后进行跟进以帮助我解决该问题。 它一直以来都是卡住的、希望 TI 工程师能够帮忙解决、谢谢！
我使用自动标记生成了 elf 文件、并验证了 elf 文件是否正常。 可以通过在 CCS 模式下烧录 CAN 消息(文件夹5)。 然后、TI 通过两种方法将 elf 文件转换为 appimage (有关这两种方法、请参阅文件夹1和2)。 两个生成的文件头会有所不同。 我将此应用图像文件与文件夹4中的刻录文件组合在一起、并将其刻录到电路板上以打印不同的错误(有关错误、请参阅文件夹1和2)。 如果文件夹3的 appimage 文件与文件夹4结合烧录、则不会报告错误。
您好！
对于上一线程的响应延迟、我们深表歉意。
Unknown 说：TI 随后用两种方法将 elf 文件转换为 appimage (请参阅文件夹1和2了解这两种方法)。 并且比较两个生成的文件头将会不同
我真的不明白你在构建 appimage 的方式的区别。 在这两种情况下、您似乎都在使用 pdkAppImageCreate.bat 本身。 但是、第二种方法似乎缺少标头、因此这显然不是创建 appImage 的正确方法。
此外、使用第1种方法、您会发现 Sciclient_procBootSetProcessorCfg
说明"R5F 向量表地址的位6：0始终为0。 如果 bootvector_lo 的位6：0为非零值、那么 TISCI 消息将返回故障。" 其中引导向量低位是您在 SBL 中的入口点。 因此、我认为您的应用起点地址的位[0：6]应是0。
我认为在查看您的映射文件时不会出现这种情况、
您能否确保满足该条件并查看它是否适合您？
您可以使用地址0x0作为入口点、以快速检查
此致、
帕尔特
您好,帕斯纳格帕尔, 感谢您的帮助! 这些天、我重复测试了 Mentor 版本、RTOS 版本和矢量版本、打印报告分别显示为文件夹(矢量版本报告的错误、我尚未解决这些问题、或者您能否将我的 elf 传输到一个附件映像供我尝试)。 我还使用 Linux 和 Windows 脚本将 elf 转换为具有相同效果的 appimage。 上次您说更改地址时、您是否将地址41c40e44更改为什么范围？ 但我想知道是否启动尚未进入 autosar、是否应该与此地址无关？
e2e.ti.com/.../vector-printf.txte2e.ti.com/.../print_2D00_appimage.rar
您好、Parth Nagpal。 我很抱歉我在一段时间前被发送到其他项目、但没有及时回复您。 这尚未完全解决、但我将入口地址从0x41c40e44更改为0x41010000 (如下面的图1所示)、这可以初始化、但并非所有加载都成功、并运行到箭头所示的位置(如下面的图2所示)。 可以成功地完全加载我的 RTOS (例如附件串行端口打印).e2e.ti.com/.../rtos-version-printing.txte2e.ti.com/.../vector-version-printing.txt 
