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.

[参考译文] CC2540:在 OAD 运行 BLE Stack 1.4.0的情况下、CC2540器件的组 A CRC 不匹配

Guru**** 2538955 points
Other Parts Discussed in Thread: CC2540

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/587290/cc2540-bank-a-crc-mismatch-for-cc2540-devices-with-oad-running-ble-stack-1-4-0

器件型号:CC2540

您好!

标题:运行 BLE Stack 1.4.0的 OAD 的 CC2540器件的组 A CRC 不匹配

背景

在我们的系统中、BLE 器件具有一个工作波特为115、200的串行端口 UART、用作主机设备的管理端口。  另一个以9600波特运行的串行 UART、用于不同的应用。

TI BLE Stack 版本为1.4.0。

在我们的 CC2540上、闪存不对称、Bank A 占据88KB、Bank B 占据160KB。 闪存的物理分区如下:

 

分区

大小(以 KB 为单位)

存储器范围

BIM       

2.

0x00000 - 0x007ff

银行_A

88

0x00800 - 0x03fff
0x2c000 - 0x3e800

组_B

160

0x04000 - 0x2bfff

SNV (2组)

4.

0x3e800 - 0x3f7ff

最后一个扇区(锁定位等)

2.

0x3f800 - 0x3FFFF

 

Bank_B 包含生产映像、而组 A 中映像的唯一目的是升级组 B。 要升级组 B、我们首先切换到组 A、升级组 B、然后切换到组 B

我们的系统还提供了在银行 B 之外运行时升级银行 A 的功能、但这一功能很少使用。

所有升级均使用 TI 提供的 OAD 设计进行、无论是无线还是串行端口。  

这是 BIM (TI 的引导加载程序)和 OAD 工作方式的重新散列:  每个图像的标头包含一个2字节的主 CRC、该 CRC 在编译期间计算并插入到标头中、而接下来的两个字节、即影子 CRC、由默认的初始化程序0xFFFF 单独保留(因为它位于闪存中)。  

启动时、BIM 首先尝试通过比较 Bank_B 的主 CRC 和影子 CRC 从 Bank_B 引导  如果影子 CRC 为0xFFFF、BIM 会计算组 B 映像的实际 CRC、将其与组 B 映像标题中的主 CRC 进行比较、如果两者匹配、则将 CRC 写入组 B 的影子 CRC、并将器件复位。 另一方面、如果主 CRC 和计算出的 CRC 不匹配、BIM 为组 A 执行相同的序列  

由于升级到组 B 需要切换到组 A、因此切换请求首先检查主 CRC 和影子 CRC 是否匹配。  如果是、则会发生切换。   如果它们不匹配、且影子 CRC 为0xFFFF (意味着我们从未在组 A 中执行过)、我们首先计算 Bank_A 映像的 CRC、将其写入影子 CRC、如果这两个匹配、 我们切换到 Bank A。 这可确保我们绝不会使系统砖墙、因为根据 TI 的 OAD 设计规则、切换到 Bank A 涉及使 Bank B 无效。

另一点值得注意:当器件从组 A 或组 B 引导时、仅以二进制形式提供的 TI BLE 堆栈会写入我们被告知位于组中间的"校准数据"。  这种情况的一个严重后果是、在发生"写入校准数据"之后、图像的 CRC 会导致组的计算 CRC 永远不匹配主 CRC、至少直到组升级。

问题说明

我们实施了一个系统、在该系统中、升级通过串行端口进行、有时使用 OAD。 在我们的 Scale tested 中的60% BLE 器件上、没有问题。  在大约40%的器件上、我们发现 Bank_A 主 CRC 和影子 CRC 不匹配。

系统是如何进入这种情况的?

结果显示影子 CRC 包含该值,就好像 CRC 是在写入“校准数据”之后计算的。  但是、TI 堆栈的工作方式是、只有当器件从组中引导时、才能将校准数据写入相应的组。

但是、在本例中、我们会将校准数据写入 A 组、这意味着我们在 A 组之外执行了、但主 CRC 与影子 CRC 不匹配、因此我们不可能在 A 组之外执行

我们不知道如何解释这种矛盾。  感谢 TI 在解决此问题方面的帮助。

此致、
KK

 

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

    随附的十六进制文件 BANK_CRC_MISMATCH.HEX (压缩后)显示了组 A 的 CRC 不匹配

    此致、
    KK

    e2e.ti.com/.../BankA_5F00_CRC_5F00_Mismatch.zip

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

    您好、KK、

    您是否在我们的已知问题页面上尝试过修复:  

    CRC 和 BIM 存在已知问题。

    还有一个问题、如何验证 imageA 是否从未运行、我了解您描述的 CRC 情况、但您是否通过调试器验证映像是否未通过调试器运行?

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

    您好 Sean、

    感谢您的更新和及时响应。

    我将介绍 CRC 和 BIM 问题。 谢谢。

    我们的器件的扫描响应指示哪个组当前处于活动状态。  此外、考虑到影子 CRC 与 Bank A 的活动 CRC 不匹配、很明显我们永远不会耗尽它。

    此致、
    KK

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

    您好!

    请告诉我 VLEN 修复是否可以解决您的问题。

    如果它仍然存在、则最好在连接 CCDebugger 的情况下重现此问题、以确保 imageA 永远不会运行。

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

    您好 Sean、

    VLEN 修复适用于 CRC 计算结果不正确的情况。  在我描述的问题中、CRC 计算是正确的。

    此致、
    KK