[参考译文] MSPM0G3519：initdone 后电路板未复位。

如果可能、请提供一些与此相关的文档。

尊敬的 TI 团队：

我们将 使用您的 CSC 示例来 满足我们的一项要求

存储体交换使能等配置进行编译。

在使用 CSC 启动代码启动应用程序代码期间、我们几乎不会遇到任何问题。

您能在下面澄清几个问题吗？

配置存储体交换时、DL_SYSCTL_issueINITDONE () 之前的延迟是否是必需的？

如果是、

建议/裸的最小循环数是多少？ 是否 160 个周期是官方的最低要求？

如果在某些情况下可以缩短或跳过延迟、具体取决于什么？

延迟实际上可以防止什么硬件机制/稳定时间？

TRM、数据表、勘误表或此稳定要求的内部设计信息中是否有任何官方时序规格（即周期/μ s/ns）？

如果您能提供见解、将会大有裨益

谢谢你。

尊敬的 Mehul、Nisarg：

很抱歉、我没有看到测试中触发的 INITDONE 和系统复位之间的延迟要求。

系统复位应在发出 INITDONE 后立即发生。 否则、可能有两种可能性：

1.未在 NONMAIN 中配置 CSC 启用和存储体交换启用。

2.在触发 INITDONE 时、INITDONE 位已置位

您可以参阅 MSPM0 MCU 中的网络安全机制（修订版 A）的常见问题解答部分 、查看是否解答您的问题。

此致、

Pengfei

尊敬的 Mehul：

我在针对整个 CSC +应用程序映像之前使用 Uniflash 编程进行了测试、从我这边可以正常工作。

由 Uniflash 对映像进行编程后、就尝试了 下电上电 、查看程序是否按预期运行？ 我是指首先针对安全配置执行 INITDONE 之前的代码、然后发出 INITDONE 并触发复位、下次执行应用程序时、也会执行该代码。  

剂量该初始完成对特定优化有严格的要求？   

尊敬的 Mehul：

我认为它与优化级别相关、因为它仅与一个寄存器操作相关。

您是否看到优化级别对 initdone 行为（是否触发器复位）有影响？

对此有何评论/更新？  

尊敬的 Mehul：

您能否检查硬故障是由哪个代码句子引起的？ 我假设这不是由 INITDONE 本身引起、而是由 INITDONE 和复位后的代码引起。 简要介绍了如何使用硬故障进行调试。

e2e.ti.com/.../MSPM0-HardFault-Debug.pptx

此外、您还可以尝试以下代码进行程序跳转、这应该对于在运行时运行 SP 更安全。

uint32_t * vector_table_backup;
static void start_app(uint32_t *vector_table)
{
    /* The following code resets the SP to the value specified in the
     * provided vector table, and then the Reset Handler is invoked.
     *
     * Per ARM Cortex specification:
     *
     *           ARM Cortex VTOR
     *
     *
     *   Offset             Vector
     *
     * 0x00000000  ++++++++++++++++++++++++++
     *             |    Initial SP value    |
     * 0x00000004  ++++++++++++++++++++++++++
     *             |         Reset          |
     * 0x00000008  ++++++++++++++++++++++++++
     *             |          NMI           |
     *             ++++++++++++++++++++++++++
     *             |           .            |
     *             |           .            |
     *             |           .            |
     *
     * */
    /* Back up of vector_table to avoid being changed because of SP update */
    vector_table_backup = vector_table;
    /* Set the Reset Vector to the new vector table (Will be reset to 0x000) */
    SCB->VTOR = (uint32_t) vector_table;
    /* Reset the SP with the value stored at vector_table[0] */
    __asm volatile(
        "LDR R3,[%[vectab],#0x0] \n"
        "MOV SP, R3       \n" ::[vectab] "r"(vector_table));
    /* Jump to the Reset Handler address at vector_table[1] */
    ((void (*)(void))(*(vector_table_backup + 1)))();
}

此致、

Pengfei

好的、但从引导加载程序跳转到应用程序时没有遇到问题。 代码跳转逻辑工作正常。 当我调用  DL_SYSCTL_issueINITDONE () 时、我会遇到问题。  

正如我在前面提到的、如果我在调用此  DL_SYSCTL_issueINITDONE () 函数之前添加一些 print 语句或更改优化级别、甚至添加延迟、那么同样的代码也可以正常工作。

嗨、Pingfei、

我是 Chris、Mehul 和 Nisarg 的一名同事正在研究同一个产品。

我是“幸运的“,遇到了以下情况:

场景：

2 个基于 CSC 的引导加载程序的相同副本、以及 1 个 使用 UNIFLASH 将我们（已签名）应用程序刷写到电路板上的副本。
 引导加载程序 会按预期运行和启动应用程序、即设置 INITDONE 时不会挂起。

然后、我 使用我们自己开发的基于 CAN 的文件传输机制将相同的（签名）应用程序上传到电路板。
请注意、   事实证明、此文件传输以及相关的刷写和存储体切换机制在许多其他情况下可按预期工作。

不过：
 引导加载程序   将应用程序写入上部     存储体、对其进行身份验证、从下部存储体中删除了之前运行的应用程序、然后尝试将 INITDONE 设置为从其引导...现在 、当 连续尝试引导时、它会挂起并保持挂起状态。

扼要重述：

• 从下部存储体运行的引导加载程序和应用程序-> INITDONE 按预期运行。
• 。 也一样 引导加载程序和 也一样 从 上部存储体运行的应用-> INITDONE 挂起。

另请注意：
我能够使用 引导加载程序的调试 (-O0) 和发布 (-OS) 版本重现同样的问题。

我同意您的以下假设： INITDONE 实际上不会挂起、但之后会发生不良情况。

因此、我进入调试器并确定代码位于硬故障处理程序的无限循环中。    异常堆栈帧中的 LR 寄存器指向 相同的代码 在 debug 和 release 版本中：

调试构建

 LR = 0xa725

映射文件片段：

0000a6e8 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)
0000a734 0000004c can_sdo.o (.text.sdo_getAbortCode)

发布版本

 LR = 0x7171

映射文件片段：

00007134 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)
00007180 0000004c flash_map_backend.o (.text.flash_area_read)

因此,在这两种情况下, hardfault 似乎 在   libc.a 的 copy_in () 结束前 16 个字节出现
我们使用的是  ti-cgt-armllvm_4.0.2.LTS。

希望这有助于确定此问题的根本原因、因为 这和之前的调查结果都清楚表明此问题不是由我们的代码引起的。
如果您有任何问题、请告诉我。

THX、
Chris。

Pingfei、

我知道这听起来很奇怪、但我开始看到一种模式：

• 当 代码段“libc.a：cpy_tbl.c.obj (.text.copy_in)“在以 0xC 结尾的地址结束时、工作方式符合预期。
•  如上所述,任何其他地址的情况都失败了（大概...我最终没有生成 一个以 0x0 结尾的地址）。

工作代码布局：

0000712c 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.2.LTS 构建
0000709c 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.4.LTS 构建
0000708c 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.4.LTS 构建
0000708c 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.2.LTS 构建
000070ec 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.2.LTS 构建

失败的代码布局：

00007138 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in) -使用 ti-cgt-armllvm_4.0.2.LTS 构建
00007158 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in) -使用 ti-cgt-armllvm_4.0.2.LTS 构建
000070f8 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in) -使用 ti-cgt-armllvm_4.0.2.LTS 构建
00007104 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in) -使用 ti-cgt-armllvm_4.0.2.LTS 构建
000070a4 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.4.LTS 构建
00007078 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.4.LTS 构建
00007084 0000004c libc.a：cpy_tbl.c.obj (.text.copy_in)-使用 ti-cgt-armllvm_4.0.4.LTS 构建

换言之：
INITDONE 故障更有可能出现、但这只是当 本应切换到上部闪存存储体时的情况。

       最近留在下部闪存存储体中时、我没有看到任何 INITDONE 故障。 但是、这种故障也会发生。

我还尝试将 工具链升级到最新的 4.x 版本、但这没有任何区别。

您好、谢：  

我浏览了 TI 的官方文档 “应用手册“
MSPM0 系列中的闪存多组功能、我找到了代码  

 Mehul Dabholkar 
我已经确认插入延迟可以 不会 帮助！ 当我把 它增大 100 倍时也不会这样。

谢鹏飞 
我对违规位置的假设 (?) 上述准则变得越来越可信。 我可能运行了数十个版本、但始终证明是正确的：

• 当 代码段“libc.a：cpy_tbl.c.obj (.text.copy_in)“结束于以 0xC 结尾的地址时，情况符合预期，并且 — 可能- 0x0（我只有一个这样的构建版本）。  
•  当 代码段 在 0x4 或 0x8 结束的地址结束时、情况会失败。

到目前为止、此行为完全可以重现。

 谢鹏飞 
我们何时可以获得有关该问题的答案？

尊敬的 Christian 和 Mehul：

很抱歉、因为我两天都不在办公室、所以反应迟来了。 很多人会考虑关于这个问题的总结。

您可以通过一种稳定的方法来重现 INITDONE 的问题。 根据您的说明、我认为这个问题看起来是新的、它可能与 INITDONE 发生期间 libc.a 上的一些内部行为有关。  

我可以在下周初参加同样的测试、如果我取得任何进展、我将向您提供最新信息。 感谢您的患者。

此致、

Pengfei

您好、谢：

对此有任何更新？

尊敬的 Mehul 和 Christian：

我尝试从我这边重现这个问题、方法是确保 “libc.a：cpy_tbl.c.obj (.text.copy_in)“起始地址与 0x4 对齐、如下面的所示、但我这边没有看到相同的问题。 （我在我这边尝试了 ti-cgt-armllvm_4.0.LTS 和 ti-cgt-armllvm_4.0.4.LTS）  。

我相信您的启动程序中有一些闪存操作（例如擦除或编程）吗？ 对于闪存操作、cpy_tbl.c 将链接并应在引导期间应用（在_c_int00 程序中应用、它在 Reset_Handler 之后和 main () 应用程序之前）、将一些闪存操作 API 从闪存复制到 SRAM。 我认为在此阶段会触发硬故障、这是在 INITDONE 实际生效之后触发的。

您能否共享链接器文件 (.cmd) 并分享您完成的闪存操作以及在引导程序中应用的 API？

您的引导程序和应用程序的存储器映射是什么？

要验证_c_ini00 程序期间是否发生硬故障、您可以尝试在 Reset_Handler () 函数中添加一个环路或触发 GPIO 切换、并检查 MCU 何时从物理 bank1 运行 bankswap 和程序、您是否可以看到程序卡在循环中（连接调试）、或者您是否看到 GPIO 切换。  

此致、

Pengfei

您好、Pengfei：

我相信您的启动程序中有一些闪存操作（例如擦除或编程）吗？

是的、确实如此。 当 我们的电路板接收、刷写并验证了一个新的应用程序映像后、它将  从相应的闪存组、开关组中擦除之前安装的映像、然后发出 INITDONE。

这是它在切换到上部存储体时“挂起“的地方、即在收到 最初安装 在下部存储体中的应用程序的更新后。

也就是说、我不确定在切换到下行银行时是否会发生同样的问题、因为 第一个“挂起“会阻止我们走得这么远。 不过、我想我们可以运行一个可以执行该操作的测试。

我认为硬故障是在此阶段（即 INITDONE 实际生效之后）触发的。

我同意这一评估。 但问题是、与可能引发此类问题的下部银行和上部银行相比、可能有什么不同。

您能否共享链接器文件 (.cmd)、并共享您完成的闪存操作类型以及在引导程序中应用的 API？

我（或 Mehul）稍后会尝试这样做。 .map 文件也一样。

我认为应用程序映像对该问题没有任何影响、因为仅涉及引导加载程序代码。 同意？

Ciao、
Chris。

也就是说、我不确定切换到较低的银行时是否会发生同样的问题、因为 第一个“挂起“会阻止我们走得这么远。 但是、我认为我们可以运行一个测试来执行该操作。

只是这样做了、现在 INITDONE 在首次引导时挂起、即在尝试切换到上部存储体时、但是 而无需之前刷写/擦除 。

换言之：
似乎只有在尝试从上部银行运行时才会出现此问题。

您能否共享链接器文件 (.cmd)、并共享您完成的闪存操作类型以及在引导程序中应用的 API？

cmd 和.map 文件附加在 init_done_issues-config-0.zip 中 2026年02月10日。

我们在该用例中使用的 API 本质上是：

嗨、Pingfei、

一个未成年人 (?) 校正：

就这么做了、现在 INITDONE 在首次引导时挂起、即在尝试切换到上部存储体时挂起、但是 而无需之前刷写/擦除 .

这不是真的。     调用 Lock_writeOut () 时,闪存的 2 个扇区将被擦除和编程。

还应注意、CSC_LOCK_STORAGE_ADDR 已移动 、而是位于 CSC 示例代码中。 它位于我们代码中的 0x14400。 原始代码为 0x4400。

这使得调用 带有 lockable_flash_firewall  = 0x00030000 的 DL_SYSCTL_setWriteProtectFirewallAddrRange () 是无用的,但它也应该没有任何危害。

我还 在 DL_SYSCTL_executeFromUpperFlashBank () 和 DL_SYSCTL_issueINITDONE () 注释掉之前运行了所有内容的测试、但问题仍然存在。

Ciao、
Chris。

尊敬的 Christian：

感谢您分享这些信息、它会提供帮助。

您是否可以在两个测试下面添加额外的测试（对一些测试感到抱歉）：

1.当问题发生时（我是指 MCU 卡在硬故障处理程序中）、尝试通过 XDS110 连接 MCU 调试（上一张幻灯片显示了有关使用正在运行的 MCU 连接调试的步骤）、然后打开“View-Disassembly"顶部“顶部菜单、并输入 “libc.a：cpy_tbl.c.obj “的地址。 检查它是否全部为 0xFF。 如果没有、我相信我们也可以从反汇编代码中确定导致硬故障的地址。

2.我想你是用.bin 文件加载 bank1 启动固件吗? 我们是否可以尝试使用.txt 文件加载、并且只需将每个数据部分的@地址更改为 bank1 基地址（例如：@0000 ->@0x40000）

请告诉我您的测试结果。 谢谢。

此致、

Pengfei

嗨、Pengfei、

我相信我们也可以从反汇编代码

以下是我 得到的结果：
硬故障处理程序中堆栈帧的 LR 固定 0xa7e5。 反汇编函数 copy_in 会显示以下情况：

当 LR 持有 0xa7e5 时、我认为这意味着在执行 0xa7e2 处的指令时发生了不良情况。
R2 似乎是函数指针。     硬故障处理程序堆栈帧中 R2 的值 为 0xffffff。

该函数被调用时或之前已经被调用时（例如在   0xa7de 加载其值时）、它可能已损坏。

我们能否尝试使用.txt 文件进行加载、只需将每个数据部分的@地址更改为 bank1 基地址（例如：@0000 ->@0x40000）

对不起,但我不明白你的意思。

Ciao、
Chris。

您好、Chris、

硬故障处理程序中堆栈帧的 LR 保存 0xa7e5。

我为 COPY_IN 函数设置了相同的测试环境（将该函数的起始地址设置为 0xa7a8，并检查了该器件的反汇编代码完全相同）、但我这边找不到硬故障问题。 我想这个问题可能不是由 copy_in 函数引起的。 您能否按照下面幻灯片的指南第 6-9 页检查硬故障原因？ 您需要检查 SP 地址中的存储器、并 在 SP 指针后接的第六个地址中找到数据。 有关详细信息、请查看幻灯片。 然后检查地址在反汇编代码中表示什么。

e2e.ti.com/.../MSPM0-Blocking-Issue-Debug-Flow.pptx

抱歉、我不明白您的意思。

我的意思是、您可以使用 ti-txt 格式作为加载的引导输出文件 BANK1 ：

1.您首先冷地配置引导项目属性以生成 ti-txt 格式的输出文件。

2.如果您打开.txt 文件,您将看到数据从“@0000“、“@41C00000“、“@41C00100“开始,您可以删除  “@41C00000“、“@41C00100“和后续内容（这是 NONMAIN 内容和 bank0 引导程序将包括这些部分）。 然后为所有其他地址添加 0x40000 偏移量（例如：@0000 ->@40000）。 并且还让我知道你是否可以看到除 “@0000“,“@41C00000 “,“@41C00100 “在您的 txt 格式文件以外的任何其他地址。

提前告诉我们,我们将从 2 月 14 日起在中国度过新年假期,我将在 2 月 26 日以后回来。 所以这个星期五之后的回复可能会有一些回复。  

此致、

Pengfei

嗨、Pengfei、

鉴于您的未决假期、我尽量快速（可能不完整）地提供更多信息。

供参考：
我们是 不会  使用 CCS 进行开发。 我们一直使用它开始使用、但我们的总体目标是独立于供应商特定的 IDE。 我们正在使用 TI 的工具链（以基于 GCC 的工具链作为替代方案） 、但否则 我们的工程基于简单的 Makefile。

如果打开.txt 文件、您将看到从“@0000“、“@41C00000“、“@41C00100“、

除了@0000 和@14400 之外、.txt 文件不显示任何其他地址。 这是因为我们   已经排除了不需要的.bCRConfig 和.BSLConfig 节。 @14400 是 我们的  lock_storage 部分所在的位置。 可能也应该从.bin 文件中删除此段、但它应该不会造成任何损害。  我附上了 完整的文件供您参考。

示例：
我不确定这是不是错误还是功能、但 TI 的  tiarmhex 实用程序只是一个错误或功能  附录 未去除符号指令的段、而不管其目标地址如何。 arm-none-eabi-objcopy 等其他工具会填充地址空间中的任何潜在空白。

因此、我们的二进制文件（以及刷写到上部存储体的引导加载程序映像）会附加一个额外的 16 字节（用零填充）。 我认为这不是我们问题的根本原因、但我会尽快尝试一下。

尽管未使用 TI 的 IDE、但现在我能够进入调试器 解决方案 出现硬故障。 这会在例程 copy_in 中显示以下内容（请注意，现在汇编代码不同，因为我运行的是代码的调试版本）：

。 突出显示 指令是 发生硬故障的地方、因为 R2 将填充 0xffffff。 R2 从 r7 和 r1 加载、其中代码当前停止。

此时、寄存器具有以下值：

R7 = 0xfd10、这似乎有效。 根据映射文件（附加了完整文件）、这是_TI_HANDLER_TABLE：

.cinit 0 0000fc00 00000148
      0000fc00 0000010d (.cinit .data.load)[加载映像、压缩= lzss]
      0000fd0d 00000003 ----[填充= 0]
      0000fd10 0000000c (_TI_HANDLER_TABLE)
      0000fd1c 00000008 (.cinit .TrimTable.load)[加载映像、压缩= zero_init]
      0000fd24 00000008 (.cinit。bss.load)[加载映像、压缩= zero_init]
      0000fd2c 00000018 (_TI_cinit_table)
      0000fd44 00000004 ----[填充= 0]

R1 = 0x2dc、似乎是 无效 或“超出范围“。  0xfd10 处的存储器如下所示：



截至[r7+R1]（以及更远）的所有内容都用 0xff 填充 、因为这超出了.text 段的末尾。

调用栈如下所示：

希望这有助于找出问题的症结所在。

e2e.ti.com/.../init_5F00_done_5F00_issue_2D00_2026_2D00_02_2D00_12_2D00_0.zip

嗨、Pengfei、

正如预期的那样、这些额外的字节 不是问题的根本原因。

Ciao、
Chris。

嗨、Pengfei、

我真诚地希望,其他人会拿起这个线程,而你在度假.
对吧？

Ciao、
Chris。

您好、Chris、

感谢您分享有关调试信息的大量详细信息。  

从测试结果来看、硬故障是由 CPU 尝试跳转到全为 0xFF 的地址而不是有效指令引起的。  

我个人认为这可能是由二进制格式文件引起的。 如您所说、二进制文件没有地址信息、默认情况下、二进制文件中的所有单独扇区都将直接连接、无需填充数据。 如果我们要设置填充数据、我们可以更改.cmd 文件、在闪存定义后添加“fill=0xFF"。“。 这个问题看起来一些单独的内容在.bin 文件中连接在一起、并导致地址访问错误。

这也是我希望用户使用另一种包含地址信息（例如，txt 或 hex）的格式作为引导输出文件作为交叉测试的原因。 我们可以首先生成一个十六进制或 txt（该文件将在较低的存储体地址中构建，因为使用 bankswap 时，程序就像在较低的存储体中一样运行）。 但是、当您通过 uniflash 将文件加载到 bank1 基地址时、您需要更改 txt 中的地址（@之后的地址）和 hex（内容扇区之前的地址）以添加 0x40000 偏移量、从而确保它们加载到正确的地址。

对不起,我会从今天的假期。 所以回复会延迟。 如果情况紧急、您可以联系当地的 TI 支持（销售）团队以获取支持、我们的 FAE 或销售人员将在我离线期间帮助您联系正确的人员。 或者、您也可以针对同一主题提交另一个 e2e 工单、我们的团队成员将在中国的新年全息日期间为其提供封面。 谢谢。