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.

[参考译文] CC2340R5:CCFG 差异会导致应用程序无法使用自定义引导加载程序启动

Guru**** 2768085 points

Other Parts Discussed in Thread: CC2340R5, UNIFLASH, SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1605570/cc2340r5-ccfg-difference-cause-application-not-to-start-with-custom-bootloader

器件型号: CC2340R5
Thread 中讨论的其他器件: UNIFLASHSYSCONFIG

您好、  

我们将 CC2340R5 data_stream 示例用作产品库的应用、并使用我们的自定义引导加载程序。 我们使用引导加载程序更新文件、并验证我们是否正确地写入闪存。 我们确信引导加载程序跳过正确。 我们认为 CCFG 的差异会导致这个问题。 正如我们从参考手册中检查的那样、差异可能是.pAppVtor param。  

我们面临的场景如下:

当我们使用 Uniflash 刷写器件时:  
 - boot.bin + app.bin + ccfg_boot.bin ,引导加载程序工作,但跳到应用程序不启动应用程序运行。

当我们使用 Uniflash 刷写器件时:  
 - boot.bin + app.bin + ccfg_app.bin ,引导加载程序和应用程序在电源重置后工作一次,它似乎引导加载程序不工作,因为应用程序没有启动。  

在 CCS v20 中进行调试后,我们意识到 ccfg_boot 和 ccfg_app 是不同的。 我附上了从 CCS 的内存浏览器获取的 ccfg_boot 和 ccfg_app 文件。 还随附了工程的 cmd 文件。

我们使用的是 simplelink_lowpower_f3_SDK_9_11_00_18、
CCS 版本:20.2.0.12__1.8.0

TI CLANG 4.0.3 LTS

artFiles.rar 


等待您的回答、因为问题非常紧急。
谢谢您、

一切都很棒

Savas

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

    您好、Savas:

    当我们使用 Uniflash 与以下工具刷写器件时:  
     - boot.bin + app.bin + ccfg_app.bin ,引导加载程序和应用程序在电源重置后工作一次,它似乎引导加载程序不工作,因为应用程序没有启动。  [/报价]

    这可能是应用程序运行一次 、在 Uniflash 编程绕过引导加载程序、但在器件重新启动后进入引导加载程序失败。

    当我们使用 Uniflash 与以下工具刷写器件时:  
     - boot.bin + app.bin + ccfg_boot.bin ,引导加载程序工作,但跳到应用程序不启动应用程序运行。

    好像引导加载程序没有正确跳转到应用程序启动。  您是否将自定义引导加载程序基于 MCUBoot 示例?   命令链接器文件 (*。cmd) 似乎源自 BLE OAD 示例、我不知道哪些定义适用于您的工程。  我注意到.cmd 文件几乎没有任何不同、这对于启动+应用程序配置来说是意想不到的。  引导加载程序(以 MCUBoot 为例)通常从闪存 0x0 到~0x6000 存在、并包含 CCFG (SYSCONFIG -> Device Configuration)、因为它应该在器件上电时启动。  在 CCS -> Project Properties -> Build -> Steps -> Post-build 步骤中生成十六进制映像、以将引导加载程序和 CCFG 包含在单个文件中:

    C:/ti/ti-cgt-armllvm_4.0.2.LTS-0/bin/tiarmhex -order MS --memwidth=8 --romwidth=8 --intel -o mcuboot_LP_EM_CC2340R5_nortos_ticlang.hex mcuboot_LP_EM_CC2340R5_nortos_ticlang

    应用程序.cmd 应通过从引导加载程序的结束地址(例如 0x6000)开始偏移闪存写入、并在编译后生成不包含 CCFG 的二进制映像:

    C:/ti/ccs2040/ccs/tools/compiler/ti-cgt-armllvm_4.0.4.LTS/bin/tiarmobjcopy basic_ble_oad_offchip_LP_EM_CC2340R5_freertos_ticlang.out --output-target binary basic_ble_oad_offchip_LP_EM_CC2340R5_freertos_ticlang_noheader.bin --remove-section=.ccfg

    然后在 Uniflash 中、您应确保选择“0x6000"作为“作为应用二进制映像的起始地址、当它准备好启动应用程序时、引导加载程序应跳转到该地址(或配置 CCFG 时、因为 OAD 示例包含每个映像的标头)。  您的用例与 basic_ble_oad_offchip 示例非常相似 、可以为您提供一些有用的指针(与 MCUBoot 配合使用)。

    要重新迭代、可以查看 SysConfig -> Device Configuration 以确定 CCFGs 之间的差异 (.bootcfg 除外、它应仅为  

    BLE OAD 基础知识 SLA
    向基本示例 SLA 添加 BLE OAD
    BLE5-Stack MCUboot OAD 指南

    此致、
    Ryan

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

    您好、Ryan、

    在一些调试和尾随一些之后。 我意识到 Power_init 函数完全阻止了 RTOS 引导加载程序出现健康跳变。

    因此我没有在引导加载程序中使用它、而是在应用程序端将其打开。 现在一切似乎都很好。

    我还有一个问题要问你。  

    单独调试应用程序、停止调试并执行硬复位(只需关闭电源并启用它)后、 我意识到即使闪存中没有引导加载程序、应用程序也正在启动。 这是怎么发生的? 如果您的数据有效、默认的 FCFG 引导加载程序是否会检查地址?

    Boot Area : 0x0 - 0x7FFFF 所有的值都是 0xFF ,我在 uniflash 上用内存浏览器检查
    应用程序区域:0x8000 — 闪存的其余部分  

    SysConfig 文件中的引导配置:

      -应用引导程序表:重定位引导程序  

      -引导配置:默认的 FCFG 引导加载程序

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

    除非后门引导加载程序引脚在复位时处于活动状态、否则不会进入 ROM 串行引导加载程序、即使如此、此引导加载程序也不知道要跳转到您的应用程序。  您描述的行为听起来像是应用程序的 CCFG 正在编程、而不是自定义引导加载程序、这是由 CCS 闪存器完成的、在这种情况下 、CCFG 的.bootcfg.pAppVtor 指向应用程序的 resetVectors、而不是引导加载程序。  如前所述、不应对应用程序的 CCFG 信息进行编程、因为需要保留自定义引导加载程序的版本。  因此、您针对器件配置提到的 SysConfig 文件应该是引导加载程序的文件、因为这是唯一应该编程的 CCFG。  这是通过在 Uniflash 中对包含引导加载程序应用程序和 CCFG 的引导加载程序十六进制映像以及不包含 CCFG 的应用程序二进制映像进行编程来实现的。  在这种情况下,我在上一次答复中提供的说明和指南应该是有帮助的。

    此致、
    Ryan