This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具与软件:
你(们)好
我在使用 CCS THEIA 和映像生成时遇到问题。
我正在从事的项目应该能够轻松地适应384kB 的尺寸。
构建时、CCS 中的存储器分配显示此情况全部正常:
但是、生成的.out 是2MB、.bin 和.appimage 接近2GB!
附加了 SysConfig 文件。
我试图将初始化模型从 RAM 更改为 ROM、但 看不到任何更改。
将.out 与 bin 和 appimage 文件附加到了一起
这会阻碍开发、因为我无法进行调试。
提前感谢您的帮助。
此致
单端
e2e.ti.com/.../UDS_5F00_SBL_5F00_OSPI-_2D00_-Copy.txt
附加下的 SysConfig 文件。 文本格式。
尊敬的 Seb:
但是、生成的.out 为2MB、.bin 和.appimage 接近2GB!
请注意、.out 不仅仅是加载到目标中的代码。 它包含仅加载到调试器的所有调试符号信息。 只有2MB 的一小部分将被加载到目标。
如果需要、我通知了该线程的编译器专家以了解更多信息。
我无法评论.bin 和.appimage、因为我不熟悉这些文件是如何生成的。
谢谢
Ki
你(们)好
我知道.out 会被调试信息夸大...因为即使所有代码都在 RAM 中正常运行、它也是一个引导加载程序项目、我似乎无法正常使用 CCS 启动调试会话。 我也尝试了使用引导加载程序示例项目、但会出现同样的行为。
调试的唯一方法似乎是通过刷写 SW、这对于每次将电路板置于串行引导模式、启动刷写脚本、然后返回到 OSPI 模式并加载不带 GEL 文件的调试会话...时、FAF 有点影响
但问题在于.tiimage 文件的大小。 我无法用它刷写电路板。
因此、我会被阻止进行调试。
期待您了解有关这方面的分辨率。
谢谢
此致
单端
我可以提供一些帮助、以加深您的理解。 但我无法告诉您解决此问题的最佳方法。
请阅读文章 二进制文件简介。 重点关注标题为 二进制文件中的空洞的部分。 基于此、下一步是查看已初始化段之间的存储器缺口是否很大。
在该线程的前面部分、您发布了一个包含一些文件的 zip 文件。 是其中一个文件 .out 初始文本文件。 使用实用程序 tiarmreadelf 检查文件中的各个部分。 它位于同一个位置 \bin 加载目录作为编译器 tiarmclang . 使用此命令...
% tiarmreadelf --sections UDS_sbl_ospi_multicore_elf_am263px-lp_r5fss0-0_nortos_ti-arm-clang.out There are 40 section headers, starting at offset 0x1f67b4: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .sbl_init_code PROGBITS 70002000 0005b8 000040 00 AX 0 0 8 [ 2] .text PROGBITS 70002100 000600 04ed40 00 AX 0 0 32 <...>
筛选输出以仅查看已初始化的段。 此类段是 type (类型) PROGBITS 和 FLG 列包含 Ax 或者 A . 使用此命令...
% tiarmreadelf --sections UDS_sbl_ospi_multicore_elf_am263px-lp_r5fss0-0_nortos_ti-arm-clang.out | findstr PROGBITS | findstr /c:" A" [ 1] .sbl_init_code PROGBITS 70002000 0005b8 000040 00 AX 0 0 8 [ 2] .text PROGBITS 70002100 000600 04ed40 00 AX 0 0 32 [ 3] .text.hwi PROGBITS 70050e40 04f340 000dd0 00 AX 0 0 16 [ 4] .text.cache PROGBITS 70051c10 050110 0004a0 00 AX 0 0 16 [ 5] .text.mpu PROGBITS 700520b0 0505b0 0002d0 00 AX 0 0 16 [ 6] .text.boot PROGBITS 70052380 050880 0001c0 00 AX 0 0 16 [ 8] .rodata PROGBITS 70053890 050a40 003c90 00 A 0 0 8 [17] .rodata.hsmrt PROGBITS 70062100 0546d0 0066c3 00 A 0 0 8 [26] .boot_info PROGBITS 00000000 000034 000004 00 A 0 0 1 [27] .cinit PROGBITS 00000100 000038 00057c 00 A 0 0 4
注释 findstr 是 Windows 命令。 应用 findstr /? 了解它的工作原理。 如果您使用的是 Linux 系统、请使用的某个变体 润滑 但是。
记住后面的第一列 PROGBITS 是该段的基地址。 请注意操作方法 .boot_info 和 .cinit 与其余部分很远。 这个差距就是二进制文件这么大的原因。
遗憾的是、我对您的版本了解不够、无法告诉您更改它的最佳方法、以便这两个部分靠近其余部分。
谢谢。此致、
-George.
正如 George 提到的、减小容器大小的关键是(重新)移动.cinit 和 boot_info 段。
我相信.cinit 之所以正确、是因为您已将其更改为 ROM 初始化模型。 如果您根据原始 SBL 示例将其改回 RAM 初始化模型、.cinit 应该会消失。
剩余的.boot_info 部分可能是您已针对具体的应用添加的内容。 您能否找到它旁边的 rodata? 在任何情况下、boot_info 的加载地址(0x0)听起来都不正确、因为这是矢量表应该的位置。
您好、George 和 Kier
非常感谢您的回答。 这是非常有用的信息。
我将对此进行研究、看看如何解决我的问题、但肯定是很好的指示。
如果实验得出结论、我会再次将问题标记为已解决。
感谢您的帮助。
此致
单端
你(们)好
为了从今天早上开始跟进帖子、遵循您的建议、图像会减少很多。 非常感谢您的建议。
我可以将板闪烁 OK。
但是、我很难获得可靠的调试启动。 对于引导加载程序项目、在闪存中刷写 SW 后、开始调试更可靠、然后使用不带初始化 GEL 的配置开始调试、连接到目标并加载符号。
但这很麻烦。 是否有更好/更快速可靠地启动调试会话 ?
此外、即使使用这种方法、有时也需要进行多次电路板复位(使用电路板上的按钮)才能正确启动、并避免 在执行 Bootloader_socLoadHsmrtFw 函数期间软件崩溃。
我渴望了解如何在构建后可靠地开始调试、因为这会大大加快该过程。
当部分代码在 XIP 中执行、而另一部分代码没有执行时、我也渴望了解图像结构。
看起来、我们目前需要刷写2个文件、但正常的经典刷写过程只需要一个十六进制文件。 我渴望了解如何达到这一点。
期待您的阅读。
此致
单端
我认为最好为上述每一个问题单独提出一个问题。
虽然非常麻烦。 是否有更好/更快速可靠地启动调试会话 ?[/QUOT]最好的调试方法是通过开发引导模式和初始化 GEL 脚本执行、但您说这不可靠。 或许在单独的 TT 中、会详细说明为什么它对您来说不可靠。