• 状态 Resolved
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 433 视图
  • 用户 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.

[参考译文] CC1314R10：CCS 生成新类型的 hex 文件

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1462315/cc1314r10-ccs-generates-new-type-of-hex-files

器件型号：CC1314R10
主题中讨论的其他器件：UNIFLASH、

工具与软件：

我使用 CC2538-BSL python 串行线下载应用程序来刷写 CC1312、效果非常好。

但是、使用该选项对 CC1314进行编程是行不通的。 进一步分析表明、intelhex python 软件包是

这是一个负责任的软件。 这很可能是因为 CCS 生成包含两个段的十六进制文件。

1个代码和2个 CCFG 数据。 这会导致 HEX2BIN 工具和 cc2538-BSL.py 中包含的函数挂起。

cc1314中的映射与 cc1312的不同、cc1312将 code+ccfg 视为一个地址范围、

cc1314将代码视为一个范围、将 CCFG 视为另一个范围。

因此、除非使用 intelhex python 软件包创建一些 desicion 来处理多个、否则这种方法不起作用

地址范围。 这目前不包括可在 Linux 上作为更新工具的 CC2538-BSL。

此致、

Gullik

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

    尊敬的 Gullik：

    事实的确如此。 我们在以下应用手册的第4.3.5节中描述了该过程： https://www.ti.com/lit/swra466

    我们在此介绍的工具尚未在 Linux 上进行测试、但可以与 Wine 配合使用。  

    此致、

    Arthur

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

    嗯,我下载了套件,它似乎是*严重*直接到 Windows。

    我想移植它、但看到它涉及很多工作。

    对于我的目标社区来说、一个可以通过串行方式重新编程的简单工具就更合适了。

    我的电路板是为串行重新编程而设计的、终端用户没有 JTAG...。

    我考虑了从 hex 文件中删除涉及 ccfg 区域的最后一部分、和

    其余的闪烁。 我必须弄清是否所有闪存都被擦除了、如果不是的话、我认为这会起作用。

    Gullik

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

    "好了,我要射了。

    下载可以正常运行的 cc1312。 cc2538-bsl.py、mdebug 设置为15、因此详细

    正在打开端口/dev/ttyUSB0、波特率115200
    从 fw089.hex 读取数据
    固件文件：Intel Hex
    正在读取固件文件：Intel Hex
    完成读取文件：Intel Hex
    正在连接到目标...
    ***发送同步序列
    在 ACK/NACK 之前获得0个额外字节
    *** GetChipId 命令(0x28)
    在 ACK/NACK 之前获得0个额外字节
    ***收到6个字节
    *** GetStatus 命令(0x23)
    在 ACK/NACK 之前获得0个额外字节
    ***接收到3个字节
    命令成功执行
       版本0x30828000
       无法识别芯片 ID。 正在尝试 CC13xx/CC26xx  //读取 ID 时出现问题
       目标 ID 0x8000、无
    ***存储器读取(0x2A)
    在 ACK/NACK 之前获得0个额外字节
    ***收到6个字节
    *** GetStatus 命令(0x23)
    在 ACK/NACK 之前获得0个额外字节
    ***接收到3个字节
    命令成功执行
    ***存储器读取(0x2A)

    CC1314也是如此

    正在打开端口/dev/ttyUSB0、波特率115200
    从1314fw088.hex 读取数据
    固件文件：Intel Hex
    正在读取固件文件：Intel Hex
    完成读取文件：Intel Hex
    正在连接到目标...
    ***发送同步序列
    在 ACK/NACK 之前获得0个额外字节
    *** GetChipId 命令(0x28)
    在 ACK/NACK 之前获得0个额外字节
    ***收到6个字节
    *** GetStatus 命令(0x23)
    在 ACK/NACK 之前获得0个额外字节
    ***接收到3个字节
    命令成功执行
    版本0x10828000
    无法识别芯片 ID。  再次尝试 CC13xx/CC26xx //一些奇怪的芯片 ID
    目标 ID 0x8000、无
    ***存储器读取(0x2A)
    回溯(最近的呼叫最后)：

    芯片识别似乎不起作用、也不起作用

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

    我认为 cc2538bsl 有点旧了。 相反、我建议从以下存储库开始： GitHub - BeagleBoard/cc1352-flasher：Python 跨平台脚本、可通过串行引导加载程序将固件上传到 CC13xx、CC2538和 CC26xx SoC。

    目前维护的工程、但并不明确地支持 CC1354。

    此致、

    Arthur

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

    "好的、我把这个带回家了、我正在检查它。 我想、源中没有"CC1314"的痕迹

    它依赖于具有类似编程加载器的 CC2674或 somesuch。

    我尝试了 swra466、这个需要一个 bin 文件、我是否会从十六进制中剥离 CCFG 段、然后把代码剥离为 hext2bin？

    我还没有查看擦除策略、我知道有两种、一种是擦除一个扇区、如果我想分析 bin、这很有意义、只需重新刷新 bin 中引用的内容、另一种是"erase_all"、我不确定它是否也是 CCFG。

    在这种情况下、需要重写 CCFG、因此我必须拥有两个 bin 文件并执行

    闪烁两次、以便将我的配置加载到 CCFG 中、而不会将用户锁定以供将来使用。

    我已经浏览过 Uniflash 8.7.0、但 CC1314只能编程为"片上"、我将其解释为使用 JTAG、不能选择 CC1314 (引导加载程序)"串行".....

    要将此推迟到未来的程序员黑客攻击：

    是否有一个工具可以将 hex 文件刷写到 CC1314中、该工具可由用户安装并在 WIN 或 Linux 上运行？

    此致、

    Gullik

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

    嗯,我必须找出魔法:

    我必须连接一个逻辑分析仪才能了解 CC2538-BSL 程序为何不起作用。

    1个同步被发送并确认正常

    2发送获取芯片 ID 并返回10 82 80 00 OK

    3发送状态并返回40 OK

    4 prog claims 得到 icepick id 被发送,不返回任何东西,没有 ACK 或 NACK

    (09 A7 2a 50 00 13 18 01 01)从50001318读取1个32位字。

    在 CC1314中似乎有这样的寄存器、但 FCFG 区域的偏移318

    但是、根据我的理解、它的地址应该相对于0x50000800、

    结果为地址0x50000b18。

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

    因此、我将尝试确定如何识别 CC1314。

    根据 Tech Ref 第273页、FCFG1区域为0x50000800

    根据第789页、Icepick 寄存器位于偏移量0x318

    我正在读取0x50000b18、然后返回

    S：09 9f 2a 50 00 0b 18 01 01
    R：00 cc 06 81 2f 80 B7 1b、即0x1bb7802f      rev 1。 晶圆 BB78 mfgr 0f2=ti

    swra466中提到的芯片 ID 0x2674似乎不是作为寄存器存在、

    但仅作为程序中的变量。

    Gullik
     

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

    仍然感到困惑：

    cc1312响应30 82 80 00

    CC1314会响应10 82 80 00

    这些是否足以识别器件？

    Gullik

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

    尊敬的 Gullik：

    对延误深表歉意。

    根据您的产品和您预期编程的器件、这可能足以识别您的器件。 但在我们自己的 SBL 程序中、我们确实手动指定要编程的器件类型。

    请记住、此识别逻辑实际上并不是必需的、因为如果 cc1352r-flaser 找不到正确的 ID、则会默认为 CC26XX 引导加载程序模式：  

    cc1352-flasher/cc1352_flasher/BeagleBoard/cc1352-flasherer src··GitHub 上的 cli.py

    此外、我使用以下过程来生成一组可单独编程的文件(固件和 ccfg)：

    • 启用 objcopy


    • 从二进制文件中删除 ccfg


    • 将 ccfg 转储到一个单独的文件中


    • 以二进制形式输出 ccfg 和固件


    您现在应该获得以下信息：

    此致、

    Arthur

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

    谢谢 Arthur、

    因此、我将有两个二进制文件、一个对应于"code"、一个对应于"ccfg"。

    (这就是我在 hex 文件中猜到的问题)

    现在、这应该足以对芯片进行编程了、我想"批量擦除"会擦除整个芯片、所以我需要同时烧录"code"偏移0x00000000和"ccfg"偏移0x50000000、应该是这样吗？ "fcfg"闪存会发生什么情况？

    CC26xx 的参数是否适合 CC1314R10？ 即、CC1352_flaser 应该能够刷写 CC1314R10？

    我尚未使用 Linux 或 Windows 上的任何工具对 CC1314进行串行闪存。 是的、我现在只需关注 CC1312和 CC1314、因为我正在进行芯片升级、我需要一种解决方案、帮助那些未配备 XDS/CCS 的"客户"尽可能简单地升级固件。 CC2538-bsl.py 填写了 CC1312的这一用途。

    我认为"bootloader doc"中描述的 CRC32是*整个*闪存、因此在二进制文件上进行计算后将出现匹配？

    至少现在、"代码"似乎在目标电路板上运行、可以让人接受。 :-)

    此致、

    Gullik