[参考译文] CC2745R10-Q1：CC2745 脚本编程–回读数据不匹配

admin

Other Parts Discussed in Thread: UNIFLASH

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1582557/cc2745r10-q1-cc2745-script-programming-readback-data-mismatch

器件型号：CC2745R10-Q1
Thread 中讨论的其他器件：UNIFLASH

尊敬的 TI 工程师：

使用官方 TI 脚本 (uniscript.py) 和 XDS110 对 CC2745 进行编程后、器件将正常工作。
但是、当我读回 IC 内容时、我注意到 CCFG 区域的一些数据与编程的文件不同。

位于地址 0x4E02002C 、则读取的值为 0x00 、而文件值为 0x01 。
范围 0x4E020750–0x4E0207CF 在编程过程中似乎已跳过。

我想确认在使用官方脚本时是否会出现这些行为、或者这些地区是否有任何特殊的处理要求。

另一个问题—我注意到,官方编程脚本首先编程 HSM 、然后是 .hex 和 .bin 间隔。
使用进行设置 Uniflash 、我首先对进行编程 .hex 和 .bin 文件、然后更新 HSM 。
我想确认这两个序列在功能上是否等效、或者顺序是否会影响结果。

此致、
哈利

3 个月前

0 admin 3 个月前

TI__Guru**** 2648525 points

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

您好 Harry、

我正在将问题分配给我在 uniscrpt.py 工作的同事。

为了解决最后一个问题、您可以更正在 uniflash 中、在刷写 HSM 固件之前刷写.hex 或.bin 工程文件。在刷写 HSM 之前、uniscript.py 脚本会刷写中间.hex/.bin 映像。然后、客户提供的.hex/bin 映像将刷写到器件中。序列在功能上是等效的。

谢谢、

Isaac

0 admin 3 个月前

TI__Guru**** 2648525 points

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

您好、Harry：

0x4E02002C 对应于 CCFG 的 writeEraseProt 位。此值取决于您是否需要在 CCFG 上编写 writeEraseProtection、它应与您要刷写的.hex 文件中的值相对应。

0x4E020750 -> 0x4E0207CF 对应于 CCFG 的 userRecord 部分、由您定义。这对 CCFG 的有效性没有影响。

此致、

Nima Behmanesh

0 admin 3 个月前

TI__Guru**** 2648525 points

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

嗨、Nima、

感谢您的答复。现在我了解了 userRecord 部分。
但是、我注意到了 writeEraseProt 位 I 读回的值与编程文件中的值不同。
脚本是否可能在编程期间修改此位？

另外、能否请您解释一下的实际功能 writeEraseProt 位 ？
我担心这可能会影响器件的行为。

再次感谢您的帮助。

此致、
哈利

Bluetooth®︎（参考译文帖）

Bluetooth®︎（参考译文帖）(Read Only)

[参考译文] CC2745R10-Q1：CC2745 脚本编程–回读数据不匹配