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.

[参考译文] LAUNCHXL-F28P65X:SCI 引导加载程序缓慢传输–字节间的16ms 延迟

Guru**** 2472510 points
Other Parts Discussed in Thread: C2000WARE

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1477364/launchxl-f28p65x-slow-sci-bootloader-transfer-16ms-delay-between-bytes

器件型号:LAUNCHXL-F28P65X
Thread 中讨论的其他器件:C2000WARE

工具与软件:

尊敬的德州仪器(TI)支持部门:

我目前正在与合作 TMS320F28P65X 微控制器并测试 闪存串行编程示例 消息流 serial_flash_programr.exe . 这个过程是实用的;但是、我正在经历 传输速度极慢 将闪存内核加载到 RAM 时。

观察结果:

  • 内核加载时间: ~8分钟
  • 应用加载时间: <1分钟
  • 测得的传输速度:
    • AT >38400波特 、无法建立转移。
    • AT 38400波特 、有效传输速率: 500位/秒
    • AT 9600波特 、有效传输速率: 404位/秒
  • 已识别瓶颈:
    • 使用逻辑分析仪、我观察到闪存内核正在传输 BSL 命令 、带有 每个字节之间的最小延迟为16ms .
    • 即使经过调整、字节之间的时间也会持续存在 COM 端口配置 .

硬件设置:

要解决此问题、我修改了设置 连接 XDS110 application/user COM UART 最终目的 SCIA XDS110目标接口连接器 GPIO12和 GPIO13 .
使用的命令: serial_flash_programr.exe -d f28p65x -a led_ex1_c28x_dual_blinky_cpu1.txt -n led_ex1_c28x_dual_blinky_cpu2.txt -b 34800 -p COM4 -v

问题:

  1. 预期引导加载程序时序: 16ms 字节间延迟 由 serial_flash_programmer.exe 引起、还是由外部因素引起?
  2. 优化传输速度: 有什么建议吗 设置、流控制机制或 USB 转串口适配器 这将提高性能?

后续步骤:

我的 最终目标 对的 将闪存内核下载到闪存 这样微控制器就可以了 始终从闪存引导 而不需要加载内核。 一旦内核存储在闪存中、我打算这样做 修改闪存内核和闪存串行应用程序 使用 我的动力总成系统中已实现了自定义协议 以确保兼容性。

任何指导 减少内核加载时间、优化引导加载程序过程并实现基于闪存的引导方法 如您所见。

此致、
Luciano Vittori

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

    抱歉:使用的命令是:
    ./ serial_flash_programr.exe -d f28p65x -k flash_kernel_c28x_dual_ex1_c28x1.txt -a led_ex1_c28x_dual_blinky_cpu1.txt -n led_ex1_c28x_dual_blinky_cpu2.txt -b 34800 -p COM7 -v

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

    您好、Luciano、

    16ms 字节间延迟来自从 Windows COM 端口读取数据所需的开销。 串行闪存编程器每次从目标读取一个字节回送的数据、因此此16ms 延迟会造成相当大的性能损失。 您可以尝试结束在 PC 上运行的其他任务、但将内核加载到器件所需的任务除外、因为有些任务的优先级可能高于 exe。 此外、您可以修改主机/内核代码、使其不依赖逐字节验证(校验和)。  

    要创建驻留在闪存中的闪存内核、您必须首先修改链接器 cmd 文件以将相应的段放置在闪存中。 您可以参阅 中的28p65x_FLASH_API_lnk_cpu1.cmd  C2000 Ware_Install_Location \C2000Ware_5_04_00_00\device_support\f28p65x\common\cmd。 您可以根据所需的行为将内核放置在 CPU1可用的任何组中。

    将现有闪存内核转换为基于闪存的应用时需要考虑的其他一些问题:

    • 您是否希望闪存内核在器件启动后执行? 或者、您是否希望其他一些应用在启动时执行、并且内核只会在收到固件更新命令时才会执行?
    • 您希望应用驻留在何处?
    • 您是否需要执行实时固件升级? 还是离线?

    如果您给我更多关于您期望的行为的详细信息、我可以提供更多指导。  

    此致、

    Skyler

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

    您好、Skyler、

    感谢您的答复。

    因此、您建议延迟是由操作系统而不是主机应用程序引起的、我可以通过绕过验证并在不读取端口的情况下发送字节来缓解这个问题。

    在我当前的系统中、闪存内核始终在启动时执行且超时、因此我想保持这种方法。 由于我不熟悉德州仪器(TI)环境和引导加载程序的开发、因此我计划进行逐步的更改。

    我认为我需要在应用程序之外的另一个库中对闪存内核进行编程。 我的想法是:

    • 组0 : Flash 内核,确保每次重置时都执行。
    • 其他银行 :应用程序存储。

    我的下一步是使用同一个主机应用程序对闪存进行编程、只对闪存内核和应用程序命令文件进行修改。

    这有道理吗?

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

    您好、Luciano、

    我不建议完全绕过验证方法、但如果逐字节验证太慢、则可以考虑替代方法。 如果没有任何类型的验证、您就会面临向设备写入大量垃圾的风险。  

    Unknown 说:
    我打算这样做 修改闪存内核和闪存串行应用程序 使用 我的动力总成系统中已实现了自定义协议 以获得兼容性。

    此处提到的协议是否依赖于 SCI 与主机 PC 的通信?

    内核与应用程序分离并不是要求、但它确实可以使您的实现变得容易得多。 您所描述的后续步骤很有意义、如果您有任何其他问题、请联系我们!

    此致、
    Skyler

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

    您好、Skyler、

    我的协议依赖于 CAN 通信、但我认为、如果我可以使此示例用作驻留引导加载程序、稍后修改应用程序逻辑将更容易。 我的计划是逐步进行修改、以充分了解流程并确保一切正常工作。

    我修改了闪存内核以及 CPU1和 CPU2应用程序的命令文件、但很遗憾、它仍然无法正常工作。

    我能够成功地与主机通信并执行诸如的命令 DFU1、DFU2、Verify CPU1和 Verify CPU2 . 但是、当我尝试时 运行 CPU1 、指示灯不闪烁。 我已在上验证应用程序是否在闪存中正确编程 0x0A0000 (CPU1) 0x0E0000 (CPU2) 、但应用程序似乎没有在运行。

    我不知道如何在这里上传文件、所以我已经在 GitLab 上上传了项目来与您分享
    28p65x_flash_programming_cpu1tocpu2_flash_28p65
    28p65x_GENERIC_FLASH_lnk_CPU1
    28p65x_GENERIC_FLASH_lnk_CPU2

    对于导致此问题的原因、您有什么想法吗?

    提前感谢您!


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

    您好、Luciano、

    我的协议依赖于 CAN 通信、但我认为、如果我能够将此示例作为驻留引导加载程序使用、稍后修改应用程序逻辑将更容易一些。 我的计划是进行渐进的修改,以充分理解流程,并确保一切正常工作。

    决定将实现移植到 CAN 时、该器件上还有适用于传统 CAN 和 CAN-FD 的类似示例。 SCI 和 CAN 示例在用户体验方面存在一些差异、但底层实现非常相似。

    发送 run CPU1命令时会出现什么行为? 器件是否分支到0xA0000的预期入口地址? 我建议逐步调试引导加载程序、查看它是否分支到正确的地址、或者在分支后是否发生 NMI/意外行为。 如果引导加载程序分支到正确的地址且 LED 未闪烁、则可能是 LED 工程出现问题。 通过 CCS 加载 LED 项目时它是否正常工作?

    此致、

    Skyler

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

    您好、Skyler、
    感谢您的答复。

    当您决定将实施方案移植到 CAN 时、我们还针对此器件上的传统 CAN 和 CAN-FD 提供了类似的示例。 SCI 和 CAN 示例在用户体验方面存在一些差异、但底层实现非常相似。[/报价]


    是的、我计划在实施过程中稍后再探讨这些示例。 现在、我的重点是将此示例用作常驻引导加载程序、以便我在转换到 CAN 之前完全了解该过程。

    发送 run CPU1命令时、您会看到什么行为? 器件是否分支到0xA0000的预期入口地址? 我建议逐步调试引导加载程序、查看它是否分支到正确的地址、或者在分支后是否发生 NMI/意外行为。 如果引导加载程序分支到正确的地址且 LED 未闪烁、则可能是 LED 工程出现问题。 通过 CCS 加载 LED 项目时它是否工作?[/QUOT]


    我启动了一个调试会话并在闪存内核执行的末尾放置了一个断点。 此时 输入地址已正确设置为 0x0A0000.

        return(EntryAddr);



    我继续逐步执行、并在结束时观察到这一点 汇编程序文件(f28p65x_codestartbranch_cpu1.asm) 、之后 LRETR指令 PC (程序计数器)设置为 0x0A0000.

    但是、因为这是一个 闪存内核调试会话 在执行此跳转后、我将失去对代码执行内容的可见性。

    我知道 LED 闪烁应用正在工作 因为在修改命令文件之前、我对它进行了测试。 但我刚刚找到了一个 关键点 此处:

    我再次测试了原始示例、  将闪存内核加载到 RAM 中 两个通路 CCS  或通过  SCI 加载程序  然后尝试了 运行 CPU1 但行为是一样的。 在这种情况下、LED 闪烁应用执行正确、但 仅在硬件复位后 .

    我怀疑我是谁 处理转换不正确 我是谁 主机应用程序误操作 .

    我应该如何继续确保正确的过渡和执行?

    我希望这有助于澄清我目前的状况。 如果您需要任何其他详细信息、请告诉我。

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

    您好、Luciano、

    然而、因为这是一个 闪存内核调试会话 、我将失去执行此跳转后的代码的可见性。

    您可以加载与 LED 闪烁示例关联的符号、以了解分支到0xA0000时会发生什么情况。 Load -> Load Symbols ->选择与 CPU1 LED 闪烁应用程序关联的.out 文件。

    此致、

    Skyler

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

    您好、Skyler:

    您可以加载与 LED 闪烁示例关联的符号、以了解分支到0xA0000时将发生什么情况。 Load -> Load Symbols ->选择与 CPU1 LED 闪烁应用程序关联的.out 文件。

    这听起来真的很有趣! 我在调试方面没有太多经验、因此我不太清楚如何正确执行该步骤。


    话虽如此、我相信我使用的是过时的文件。 重新编译并测试所有内容后、我可以确认 闪存内核作为驻留引导加载程序现在正在工作! 所以、我提到的最后一个项目现在已经完全可以运行了。

    非常感谢您的支持!
    此致、
    Luciano