• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 48 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] MSPM0L1304：BSL 启动应用程序命令不起作用&&#39

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1508417/mspm0l1304-bsl-start-application-command-doesn-t-work

部件号：MSPM0L1304
Thread 中讨论的其他器件：MSPM0C1106、

工具/软件：

您好、

启动应用程序命令似乎不起作用。 以下是我正在做的工作：

  1. 使 invoke_BSL 引脚生效并复位 UC
  2. 可通过 I2C 访问 BSL
  3. 发送 BSL_CONNECT 命令
  4. 发送 bsl_start_application 命令

我希望该应用程序会启动。 但事实并非如此。 请注意、invoke_BSL 引脚仍有效。 不过、如果未设置 invoke_bsl、它似乎正常工作。 但这是我们*不能*做的事情。 关于一点背景:这 UC 是在 SoM 上使用的,它也运行了 Linux ,在那里我们有一个恢复模式。 如果恢复模式处于活动状态、则 Invoke_BSL 引脚会一直置为有效。 因此、 在复位时、无论刷写了什么二进制文件、它都应引导至 BSL 以引导 UC。 复位后、SoC 的引导加载程序将(重新)刷写 UC 或启动刷写的应用程序。 不幸的是、后者不起作用。

此致、
-迈克尔

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

    您好、Michael：

    我认为问题是 BSL 调用引脚一直被置为有效。  根据 TRM 中的时序图第3.2.3节、您必须在不早于 数据表第7.8节中指定的 t_start 时间将此引脚置为无效。

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

    尊敬的 Dennis：

    我不同意、TRM 规定(第3.2.3节)：

    GPIO 应在 POR 之前置为有效、并且此状态应在 POR 后至少保持 T_start ms。
    然后、可以取消置位 GPIO 引脚状态。

    因此、T_start 只是为了确保在 POR 后正确地对引脚采样。 无需再次发布。 此外、根据图3-2。 T_start 是引导代码退出 Thinking之前的时间

    此致、
    -迈克尔

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

    您好、Michael：

    我已联系我们的设计团队、检查 BSL 调用引脚上所需的特定行为。

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

    您好、Michael：

    我得到了 设计人员的响应。

    是的、该引脚应取消置位。 每当引导重新运行时、都会检查引脚。 第2.4.1.6节"复位原因"提到、BCR 执行在 BSL 进入/BSL 退出复位后发生。 因此 BSL 调用检查再次发生。

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

    尊敬的 Dennis：

    这非常遗憾、 任何数据表/BSL doc/TRM 中都没有提到它。

    "启动应用程序"命令与 MCU 复位之间有何区别？ 对我来说、这看起来像是引导 ROM 中的一个错误、您能确认一下吗？ 另外、我未能看到"第2.4.1.6节复位原因"和"启动应用程序"命令之间的相关性。 您能详细说明一下吗？

    谢谢、
    -迈克尔

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

    您好、Michael：

    是的、我同意文档没有明确说明这一点、因此我正在与我们的系统团队合作获取文档的更新。

    我查看在 第98行中检查 BSL 引脚的代码(见下文)(blInvocation_checkPinCondition)。  从第144行开始检查引脚状态、如果引脚状态与预期状态匹配、我可以告诉它简单地返回 true、否则返回 false。  在本例中、这是因为将 BSL 调用引脚保持在高电平。

    因此,在 pin check 返回 true 后,我期望代码在第101行返回 true , 退出 do..while ()循环。  否则、代码会一直在循环中调用 blInvocation_checkPinCondition()、直到10秒 BSL 超时到期、BSL 被锁定、CPU 进入睡眠模式。  请参阅 MSPM0引导加载程序指南中的第3节" BSL 架构"。  让我把它呈现给我们的 BSL 团队进行注释。

    顺便说一下、如果您尚未发现闪存 BSL 源代码、它位于 SDK 中的以下位置：

    C：\ti\mspm0_sdk_2_05_00_00_internal\examples\nortos\LP_MSPM0C1106\bsl\flash_bsl

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

    尊敬的 Dennis：

    感谢您的指导。 从代码(这不适用于 MSPM0L1304 btw、但我怀疑这里很重要)中可以看出、"启动应用程序"只是一次复位。 如果确实是这样、则该命令的名称确实是*redley*错误。 因为我假设、如果引导加载程序有一个"start application"命令、它通常会执行类似的操作、例如"跳转到应用程序入口点"、而不仅仅是复位 、并让引导加载程序(再次)找出后续步骤。 因此、如果它只是"reset"、则更有意义。

    谢谢、
    -迈克尔

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

    您好、Michael：

    我不会反对你,"开始申请"可能有点误导,这意味着.