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:BLE 模块在 Linux 上使用 SBL 工具通过 UART 刷写成功、但没有 BLE 广播

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1514483/cc2340r5-ble-module-flashing-via-uart-on-linux-using-sbl-tool-succeeds-but-no-ble-advertising

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

工具/软件:

尊敬的 TI 团队:

我正在使用基于 CC2340R5的定制 BLE 模块、并尝试使用 cc2340-bsl.py 脚本(Linux SBL 工具: https://github.com/Shuyang-z/cc2340-bsl)通过 UART 进行刷写。 虽然脚本报告成功进行了闪存和 CRC 验证、但该模块不会启动 BLE 广播、而应该在刷写后执行该操作。

设置:

MCU:CC2340R5N0RGER (空白芯片)

主机操作系统: Debian 11.11.  

刷写工具:cc2340-bsl.py  

固件文件:.hex、根据 SIMPLELINK-LOWPOWER-F3-SDK v8.10.01.02中的 BLE 外设示例构建

UART 端口:/dev/ttyUSB0

波特率:115200

连接方法:USB 转 UART 适配器(与 UniFlash 和 LaunchPad cc1252p7-1配合使用正常)

闪存命令:python3 cc2340-bsl.py -p /dev/ttyUSB0 -b 115200 -e -w -v /home/ops/Downloads/basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex


输出:

python3 cc2340-bsl.py -p /dev/ttyUSB0 -b 115200 -e -w -v /home/ops/Downloads/basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex
正在打开/dev/ttyUSB0端口、波特率230400
读取/home/ops/Downloads/basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex 中的数据
固件文件:Intel Hex
正在连接到目标...
正在执行批量擦除
擦除所有 MAIN 存储体闪存扇区
擦除完成
在0x4E0207C0C8处写入64个字节
写入 CCFG 完成
在0x0007FFF098处写入16个字节
写入 MAIN 闪存完成
通过比较 CRC32计算进行验证。
MAIN FLASH 已验证(匹配:0x21006695)
CCFG 已验证(匹配:0x22ca400f)

引导加载程序进入和复位:

DIO21在为模块供电以进入引导加载程序模式之前被拉至低电平(通过在发送0x55时进行确认来验证)

刷写后、DIO21被释放(使用10k 电阻器拉至高电平)。

复位是通过脚本完成的、我还尝试了手动切换、仍然没有 BLE 广播。

工作原理:  

通过 Windows 上的 UniFlash 刷写完全相同的.hex 文件(使用 LaunchPad cc1352p7-1)会导致正确的 BLE 行为—器件会立即开始广播。

脚本完成刷写和验证、没有任何错误。

我怀疑脚本会将固件写入不应该写入的地址。

我已经检查了 ccfg_address、cfg_size、flash_size 和 page_size、它们在脚本和固件中都匹配; 如果我更改地址、脚本就会失败。  


感谢您的任何指导—谢谢!

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

    您好:

    感谢您联系我们! 我们将查看您的问题、并在周一(5/18)之前回复您。

    此致、

    Tarek

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

    您好:

    感谢您的耐心! 简单问题、您是否能够让另一个应用程序使用相同的刷写流程运行? 此外、  ADC 和系统性能 您是否可以使用最新的 SDK 或8.40 SDK 尝试此操作?

    回答这些问题将帮助我们确定问题的确切位置。

    此致、

    Tarek

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

    您好、
    谢谢。 我使用 SDK v8.40.02.01尝试了该方法。 十六进制文件成功刷写、我的器件现在按预期广播。 但是、我想问一下、当使用以前版本的 SDK 生成相同的十六进制文件时、为什么没有进行刷写。 我们的大多数工程都基于早期版本的 SDK 构建、因此我们希望 SBL 工具也能与这些工程配合使用。

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

    您好:

    我很高兴听到它的工作! 我不确定为什么在8.10 SDK 上发生这种情况、原因可能有多种。 如果这是妨碍您在开发/生产流程中取得进展的问题、我可以尝试进行研究。

    但是、我始终建议迁移到更新的 SDK、因为这将包括对早期版本中出现的许多错误的修复。 如果您希望获得迁移到8.40 SDK 的帮助、请参阅用户迁移指南的部分:

    https://dev.ti.com/tirex/explore/node?a=58mgN04__8.40.00.61&node=A__AJK4IB6.SQXkn4DIcgE1hA__com.ti.SIMPLELINK_LOWPOWER_F3_SDK__58mgN04__LATEST

    我希望这对您有所帮助!

    此致、

    Tarek

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

    您好、
    我们有一些器件已投入生产、其固件已在以前版本的 SDK 上开发。 我们还必须紧急将它们寄给我们的客户。 虽然我们将确保为即将进行的工程使用最新的 SDK 版本、但如果您能一开始就告诉我们导致此问题的原因、那您会非常好。
    非常感谢您的指导。

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

    您好:

    我会仔细研究一下、尽快告诉您!

    此致、

    Tarek