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.

[参考译文] AM263P4-Q1:CCS THEIA 中的映像生成问题- bin 和.tiimage 非常大!

Guru**** 2117280 points
Other Parts Discussed in Thread: SYSCONFIG
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1450857/am263p4-q1-issue-with-image-generation-in-ccs-theia---bin-and-tiimage-are-huge

器件型号:AM263P4-Q1
主题中讨论的其他器件:SysConfig

工具与软件:

你(们)好

我在使用 CCS THEIA 和映像生成时遇到问题。

我正在从事的项目应该能够轻松地适应384kB 的尺寸。

构建时、CCS 中的存储器分配显示此情况全部正常:

但是、生成的.out 是2MB、.bin 和.appimage 接近2GB!

附加了 SysConfig 文件。  

我试图将初始化模型从 RAM 更改为 ROM、但 看不到任何更改。

将.out 与 bin 和 appimage 文件附加到了一起

e2e.ti.com/.../2063.Debug.zip

这会阻碍开发、因为我无法进行调试。

提前感谢您的帮助。

此致

单端

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    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 .  使用此命令...

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    % 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
    <...>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    筛选输出以仅查看已初始化的段。  此类段是 type (类型) PROGBITS FLG 列包含 Ax 或者 A .  使用此命令...

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    % 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
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    注释 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 中、会详细说明为什么它对您来说不可靠。