[参考译文] CC2640：无广播-简单外围器件- CC2640

您好！

感谢您联系我们。 您能否共享您使用的 SDK 版本？ 您是否能够可靠地重现此行为？ 您是否可以在发生该行为时连接调试器并共享调用堆栈？

此致、

1月

您好、Jan：

感谢您的快速响应。

以下是对部分问题的解答。

1. 可以分享您正在使用的 SDK 版本吗?

   我们项目中使用的 SDK 为4_30_00_08

2.您是否能够可靠地重现此行为？  

重新刷新软件即可解决此问题。 但无法再次可靠地重现此行为。

3. 是否可以在发生该行为时连接调试器并共享调用堆栈？

我们尚未尝试连接调试器、因为重新刷新后、我们不知道如何再次重现此问题。

您好！

理解、感谢您提供更多细节。 如果可能、我建议将您的 SDK 更新到最新5.30版本。 自4.30以来、SDK 中进行了许多修复和改进、因此新版本可能解决了您看到的行为。 中有多少个器件出现此行为？ 您能否描述设备所在的环境？

此致、

1月

尊敬的 Jan：

感谢您的答复！

以下是对中提出的问题的解答。

中有多少个器件出现此行为？

每两个月派送大约1万个产品、其中20到25个产品有问题

2.  您能描述设备所在的环境吗?

BLE 芯片用于两轮车速度表

尊敬的 Jan：

我们已经通过 Smart RF 闪存编程器读取缺陷芯片软件。

并将其刷写到另一个工作正常的芯片中

并发现、在正常运行的产品中观察到的相同行为(BLE 芯片不发起广播)。

请帮助我们 解决此问题。 如果是、会发生任何自旋锁、如何识别发生的原因？

您好！

为了澄清、您说的是、您读取了器件的整个闪存、然后将该闪存写入工作器件的整个闪存中？

此致、

1月

您好、Jan：

我们已读取从0x00000000至0001FFF2的内存

您好！

我懂了。 感谢您的澄清。 您能否在调试器处于故障状态时将其连接到设备、并报告调用堆栈的外观？

此致、

1月

您好！

该问题将在刷新时恢复。

假设我们将调试器与 ble chip 连接、则会导致回流。

请告诉我如何在不重新刷写的情况下调试软件

您好！

应该可以在不引起复位的情况下将调试器连接到器件。 所以如果您能够闪存您的镜像并显示运行的行为、那么您应该能够连接调试器而不进行复位、并从运行的目标中提取调试信息。 请参阅以下 E2E 主题：

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/432770/cc2640-connecting-to-a-running-target

此致、

1月

尊敬的 Jan：

 从工作(正在广播)和不工作(正在广播)仪表中读取 Bin 文件。

按以下方式进行了一些分析、请检查这一点、

控制器和 BLE 芯片之间的 UART 通信序列  

将 BLE 名称发送到 BLE 芯片的每个周期控制器。

BLE 芯片接收 BLE 名称并使用写入 SNV  OSAL_SNV_WRITE API。

在分析两个 BIN 文件(工作和不工作)时、我们发现 闪存的地址存在一些差异 (从0001E000开始) SNV 所在的位置。

在正常运行的 "bin file"中、BLE 名称在每个"on"周期中使用 SNV 编写。

但是、当不起作用时 、"bin file "找到的文件会更改 BLE 名称、该名称在每个"on"周期中写入 SNV 中。

注意： 控制器在每个"开启"周期发送相同名称。

请指导我们了解 SNV 上 BLE 名称发生此更改的原因("BLE 名称"中的字母替换为无用值)

示例：  

仪表不工作

控制器至 BLE -"SAS020000000"

SNV 中的数据-"SA#020000000"

结论:两者不一样

工作仪表

控制器至 BLE -"SAS020000000"

SNV 中的数据-"SAS020000000"

结论-两者相同

以下是另一项分析、请检查它以供参考、

在 BLE Tx 引脚中以一米的形式引入噪声(函数发生器的帮助)、并进行500个"开启"周期、最后重新创建了问题。

然后读取 bin 文件。

将此 bin 文件与无法正常工作的 bin 文件进行比较、发现 SNV 中写入的 BLE 名称有类似的更改。

注意： 此处附加了正常工作和不工作的 BIN 文件(SNV 中的 BLE 名称)的 snip、以供您参考

无法正常工作- SNV 中的 BLE 名称-突出显示的部分已更改-发送 BLE 名称的控制器为 SAS020544170

结论：控制器发送的 BLE 名称的更改

工作区- SNV 中的 BLE 名称-发送 BLE 名称的控制器是 SAS020000010

结论：从控制器发送的 BLE 名称没有变化

您好！

感谢您提供更多详细信息、我不知道为什么现在会发生这种情况。 我认为我们需要连接一个调试器(不将器件复位)来监控应用的状态。 这是我们可以遵循的一种可能的调试策略吗？

此致、

1月

尊敬的 Jan：

在我们的产品中、我们将运行两个任务。

用于进行调试、以便从两个任务中激活 LED。

电路板上电时、软件正常运行、直到执行  BIOS_start() f 操作。

但是两个任务未被执行并且已从 LED 的状态中确认。

您能否说明任务未能执行的原因。 即使 BIOS_start()函数也是从 main 函数执行的。

尊敬的 Jan：

以下调试策略用于分析以供参考、

在工作软件中、启用 LED 闪烁以进行分析-构建软件并生成 bin 文件。 (测试软件)

读取故障群集 bin 文件并从(SNV 0X0001E000)复制数据。 直到最后一行。

 使用复制的缺陷群集 bin 数据替换测试软件的 bin 文件部分(0x0001E000)。

以 LED 闪烁为基准完成分析。

观察结果：

1. "static uint16 compactPage ()"  nvocop.c 文件中的函数是 triggerd。 (路径：C：\ti\simplelink_cc2640r2_sdk_4_30_00_08\source\ti\blestack\services\nv\cc26xx\cc26xx src)

2.在该函数中有一个 while 循环。

3.在 while 循环中、在一些迭代之后、执行"void HalFlashRead (uint8 pg, uint16 offset, uint8 *buf、uint16 cnt)"函数时、软件将被结构化。

4.在"HalFlashRad" 函数中、当指针变量" PTR" 值变为0x00020000 (存储在指针变量中的地址)

查询：

1.当这种情况下  "static uint16 compactPage ()" 会被触发？ (任何故障情况？？)

2. . 运行良好的软件  "static uint16 compactPage ()"  没有被触发。

3.请解释其目的   "static uint16 compactPage ()" 位置。

4.为什么当"ptr"值变为0x00020000 (存储在指针变量 ptr 中的地址)而执行  "HalFlashRead ()"时、该代码会被构造

您好！

只要闪存的 SNV 区域中必须进行压实、就会调用该 API。

我希望只要有时间进行压缩、就会调用此 API、因此这可能会告诉我们只有在必须执行压缩时才会发生问题。

该 API 用于对 SNV 执行压缩、这样做是为了尽可能地减少擦除周期的数量。 只有当扇区具有80%的无效数据时、才应进行压实。 用户指南的以下一节提供了与此相关的更多详细信息：

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-common/flash_memory-cc2640.html#simple-nv-flash-storage-overview

Unknown 说：

4.为什么当"ptr"值变为0x00020000 (地址存储在指针变量 ptr 中)而执行  "HalFlashRead ()"

我不知道为什么会发生这种情况。 您能否使用存储器浏览器来查看此地址中的内容？

此致、

1月

尊敬的 Jan：

您能否列举 BLE 芯片(即使已通电)中"无广告"的原因(硬件和软件原因)

您好！

导致设备不在广播的原因可能有几种不同：

1.可能已建立连接。 默认情况下、如果已达到最大连接数、SDK 示例将停止广播。

2.广播已被 API 禁用

3.出现过多的连接和数据传输,导致广播被跳过,因为连接事件被赋予更高的优先级。

设备在您预期的时候未在广播吗？ 您能否检查应用程序是否已收到禁用广播事件？

此致、

1月

尊敬的 Jan：

请澄清以下提到的要点、

已配置 SNV 部分的前4个字节表示什么。 (在我们的产品中、SNV 部分的起始地址为0x0001E000)

2.并且还澄清了为什么这个函数"static uint16 compactPage ()"仅在前四个字节的值时触发(在下图中突出显示)

00。 如果任何值(01,FF)至少出现在这些字节中的任何一个,则 不会触发函数"static uint16 compactPage()"。

如何检查  BLE 5栈代码中的 OSAL_SNV 配置。 检查预定义值时未获取任何信息。

4.假设配置如下所示、这是什么意思？

OSAL_SNV = 1 (SNV 配置将是什么)或

OSAL_SNV = 2 (SNV 配置将是什么)或

OSAL_SNV = 0 (SNV 配置将是什么)或

5.什么是默认 OSAL_SNV 值？？

尊敬的 Jan：

请解释以下提到的要点

1.请详细说明活动页面和转移页面。

SNV 标头(SNV 起始字节的前四个字节)与活动页和传输页之间的关系

3.in 下面提到的代码 snip、只要 else if 条件将被触发。

if ( pgHdr == NV_ACTIVE_PAGE_STATE )
 ｛
       HAL_ASSERT_FORCED ()；
       UART_WRITE (UartHandle、&testconn_1_0[0]、6)；
    findOffset()；

  }
 否则为(pgHdr =NV_Xfer_PAGE_STATE)
 ｛

    findOffset()；
    compactPage()；

  }

您好！

Unknown 说：

1.请详细说明活动页面和转账页面。

我相信活跃的页面就是正在读取或写入的页面。 我认为传输页是在压缩过程中用于传输数据的页。

我认为第2个字节指示页面是处于活动状态、是正在传输、还是其状态为任何。

3.in 下面提到的代码 snip、只要 else if 条件将被触发。

if ( pgHdr == NV_ACTIVE_PAGE_STATE )
 ｛
       HAL_ASSERT_FORCED ()；
       UART_WRITE (UartHandle、&testconn_1_0[0]、6)；
    findOffset()；

  }
 否则为(pgHdr =NV_Xfer_PAGE_STATE)
 ｛

    findOffset()；
    compactPage()；

  }

如果在调用该函数之前的传输过程中使用了页眉、则会发生其他情况。 由于这是在 INIT 函数中的、因此如果在传输发生时器件复位、可能会发生这种情况。

此致、

1月

尊敬的 Jan：

感谢您的宝贵支持!

GAP 配置如下图所示。

我们的问题是、 由于设置"绑定= true "、将会发生什么情况

如果我们使它 "绑定= false ",那么会发生什么。

请详细解释。

justwork 配对、绑定方法之间是否存在任何关系？

注意：在我们的产品中、我们没有使用 PASSKEY 方法、因此配置了"MITM = False "。

尊敬的 Jan：

在 BLE 应用代码中、我们将在 SNV 中写入 BLE 名称、如下图所示。

当我们通过 Smart RF 连接读取 SNV 存储器时、发现标头0x81和长度12会自动修改。 请解释这些静态值被修改的原因、或下面附加的尖嘴导致修改的原因。

注意：请同时澄清之前的查询

您好！

您是否可以尝试使用 UniFlash 读取该地址并检查地址是否也被修改？

为了澄清、您询问了启用或禁用绑定时 SNV 如何工作？

此致、

1月

尊敬的[JAN]：

以下是对部分问题的解答。

 您是否可以尝试使用 UniFlash 读取该地址并检查其中是否也修改了该地址？

是的、我能够使用 UniFlash 读取 SNV、并确认数据存在。 不过、我发现存储的数据不是我想要的有效数据。 在代码中、我尝试存储以下数据：

 - ID："0x81 0x00"
-长度："0xC0 0x00"
-后面是12字节的数据。

 使用的命令为：  
OSAL_SNV_WRITE (0x81、0xC0、&BLE_SNV[0] Tx_Buff)

 但是、在 SNV 中、它编写如下：
-"89 00 C0 00 xx xx xx..." "
-"A1 00 C0 00 xx xx xx..." "和类似的

修改了 ID

修改了长度

如 UniFlash 屏幕截图(随附供您参考)所示、ID 区域在写入过程中会被处理/损坏。 ID 显示为"89 00"或"A1 00"、而不是预期的"0x81 0x00"；同样、长度字节修改为"0C 04"或"0C 80"、而不是预期的"0x0C 0x00"。

您能否帮助说明导致此问题的原因？ 具体来说、在写入过程中这些 ID 和长度差异的根本原因可能是什么？

2.为了澄清、您询问在启用或禁用绑定的情况下 SNV 如何工作？  

是的、我想知道 SNV 是如何工作的、还想知道 BLE 连接有什么区别。

期待您的答复。

您好！

感谢您提供详细的细分信息。 我不知道为什么会发生这种行为。 用户指南的以下部分介绍了 SNV 的工作原理：

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-common/flash_memory-cc2640.html#flash

在此链接中、还有一个使用 SNV 的代码片段。 您能否尝试将该代码片段添加到示例项目中并查看您是否看到同样的行为？

此致、

1月

您好 Jan：

感谢您的支持！

问题概述

蓝牙功能突然停止工作、并且没有广播。

我查看了您提供的链接、 "闪存布局和使用" 并试图了解问题的根本原因。 然而,我无法确定问题。

最初、我只观察到 ID 和 Length 在 SNV 写入过程中修改了字段。 下面、我将详细解释这些问题、以便更好地理解：

详细的观察

问题1：在 SNV 写入过程中正在修改 ID

• ID 被随机修改、这种行为的概率为1/20 (不一致)。

问题2：在 SNV 写入过程中修改了长度

• "长度"字段间歇性更改、其概率与问题1相似。

这两个问题都是随机的、并且不遵循一致的模式。 尽管参考了共享文档和 技术参考手册(swcu117i) 我无法确定根本原因。

注意：
在osal_snv_write(0x81, 0xC0, &BLE_Tx_Buff[0])函数中：

• 用户没有修改的直接访问权限 ID 或者 Length 磁场的消除。
• 用户只能传输1个字节的 ID 和1个长度字节。
• 在内部、SDK 执行字写操作、并将这些值键入2个字节。

其他观察到的问题

问题3： 间歇性地、ID 和数据被修改和写入FFFF、而不是 81 00

• 这种行为会一直持续到剩余的 SNV 内存被填满为止FFFF。

问题4： 数据的某些部分会间歇性修改和写入为 FFFF

• 此问题也会一直持续到剩余 SNV 内存被填满为止FFFF。

问题5： 16个字节(或更多)数据被写入 SNV 堆栈区域之外

• 数据会溢出到意外的存储区域。
• 某些数据正在写入 CCFG 堆栈内存 、与设计不符、违反了预期的内存映射配置。

该 BLE 模块用于电池供电的应用、不可能出现低电压情况。 但是、由外部因素引起的电压波动的可能性可以忽略不计。

在该osal_snv_read过程中、如果出现电压波动、对数据的潜在影响会是什么？

 

请查看这些详细信息、并提供有关解决这些问题的见解。 如果需要其他信息、请告诉我。

 

谢谢！

您好！

感谢您的深入调试并分享调查结果！ 这很有帮助！ 我同意这似乎很奇怪。 我还有几件事想尝试

1.您是否可以尝试在出现"停止广播"问题后暂停设备的执行? 我想了解器件是否卡在某个位置。

2.您是否有机会在最新的5.30 SDK 中重现此问题？ 可能已在后续版本中解决了这一问题。

3.能否在程序执行过程中监视堆/堆栈的使用情况。 当问题开始发生时、了解我们是否接近最大堆容量会有所帮助。

4.您提到设备使用的是电池。 我不认为这是问题、但为了完整起见和完全排除电池问题、您是否可以尝试重现此行为、以关闭电源？

此致、

1月

1."您可以尝试在发生"停止广播"问题后暂停器件的执行吗？ 我想了解器件是否卡在某个位置。

我们观察到代码中的以下行是执行卡住的(在压缩过程中)：

static uint16 compactPage () HalFlashRead (NV_PAGE、srcOff、(uint8 *)&HDR、FLASH_WORD_SIZE)；  

while (cnt--)

｛

 *buf++=*ptr++；

}

该问题表现为随机、并且在多次压实周期后发生、因此很难预测何时准确发生这种行为

2.您是否有机会在最新的5.30 SDK 中重现此问题？ 可能已在后续版本中解决了此问题。

我们目前使用 simplelink_cc2640r2_sdk_4_30_00_08作为应用程序开发的基础。

目前、由于项目相关性和时间限制、我们无法升级到5.30 SDK。

o UR 首先也是最重要的优先事项是确定此故障的根本原因  当前 SDK 版本中。

3.能否在程序执行过程中监视堆/堆栈的使用情况？ 当问题开始发生时、了解我们是否接近最大堆容量会有所帮助。

您能不能为我们介绍一下可以在何处以及如何监控 堆/堆栈使用情况 优先级？ 您是否为此推荐了特定的工具或方法？

这一问题不会一直出现；它只有在多个开发板上进行多次压缩周期后才会出现、这使得跟踪代码运行具有挑战性。

4.您提到设备使用的是电池。 我预计这不会是问题、但为了完整起见和完全排除电池故障、您是否可以在使用电源运行时尝试重现此行为？

是的、我们已经使用 电源执行了基准仿真、并且问题仍然是可重现的。

此致、

Elango

尊敬的 Elango：

感谢您发送编修。 关于堆分析、我们在下面的链接中提供了有关如何执行此操作的指南：

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-memory-problems

很高兴我们能够排除电源。 要确认、您是在 Launchpad 还是定制电路板上看到这种情况？ 如果它在定制电路板上、那么您能否在 LaunchPad 上重现此情况？ 这将允许我再现我的一面、有希望加快调试。

此致、

1月

您好 Jan：
感谢您的反馈和持续支持！

1月： 您在 LaunchPad 或定制电路板上看到过这种情况吗？
回复： 我使用的是 开发板 进行开发、我在我的定制板上看到了这一点。

1月： 如果它在定制电路板上、那么您能否在 LaunchPad 上重现此情况？ 这将允许我再现我的一面、有希望加快调试。
回复：

1. 我可以尝试在 LaunchPad 上重现问题、但这样做会有一些限制。 BLE 模块与主应用微控制器通信、在 LaunchPad 上测试该设置需要修改硬件和软件。
2. 此外、在我的定制电路板上进行测试期间、花费的时间超过了 400个压实循环 从而重新造成该问题。 在调试模式下、在 LaunchPad 上复制相同的行为可能具有挑战性。

您能否建议一种替代方法来帮助更有效地识别和解决此问题？

期待您的建议！

此致、
Elango

尊敬的 Elango：

感谢您确认硬件设置。 如果您要在定制应用中以特定的速率执行写入、则也许可以简单地基于以相同速率执行的计时器执行虚拟写入。 这可能允许以自动方式重现行为。 拥有一个快速可靠地演示行为的项目对于我本人和研发团队(如有必要)的调试非常有用。 查看 LP 上是否发生该行为还可以缩小任何硬件原因的范围。

此致、

1月