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.

[参考译文] CC2564MODN:在执行 Bluetopia 调度程序时、STM32L4随机硬库

Guru**** 2581345 points
Other Parts Discussed in Thread: CC2564

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/812641/cc2564modn-stm32l4-randomly-hardfaults-when-executing-bluetopia-scheduler

器件型号:CC2564MODN

您好!

 我们在调试 CC2564MODN 和  运行 BTPS 4.0.2.2的 STM32L476RG 的硬故障错误时遇到困难。  CC2564MODN 和 STM32L476RG 通过 UART 进行通信。

详细信息:

  • 器件芯片组:4.1
  • BTPS 版本:4.0.2.2
  • 项目类型:6.
  • 固件版本:7.35

我们有一个 EMC 认证软件、可在具有 BLED112软件狗的 PC 上运行。 该软件狗  通过 BLE 连接到 CC2564、并发送串行命令(基于 SPPLE 演示)以创建流量、 而 CC2564 会尽快(16ms)发送有关另一标准服务的通知。 在这些条件下进行大约1h 的测试后、STM32L476RG 会陷入硬件故障、而调用栈会指示它正在 Bluetopia 回调中运行、我们没有蓝牙回调的源。 我们更频繁地看到来自两侧的高 BT 流量和 BT 流量的硬故障。

调用栈指示它发生在 HCITR_COMDataCallback_UART 中、根据 汇编和寄存器的值、它发生在调用 HCILL_ReceiveBytes 之前。 STM32的寄存器 R6始终包含一个 RAM 地址(0x20001800)、该地址位于映射文件中映射的值之外(STM32的堆栈和堆之外以及 Bluetopia 的堆之外)、而 R4和 R5始终指向 Bluetopia 堆中的相同地址。 很难提取任何信息、因为我们不知道 HCITR_COMDataCallback_UART 和 HCILL_ReceiveBytes 的作用是什么、它是随机发生的(不使用任何特定的 BLE 命令)。

 

正如其他文章中建议的那样、我们增加了堆大小(Bluetopia 的堆= BTPS_MEMORY_buffer_size)、并且仍然发生错误。 我试图减小堆大小、只是为了查看它是否会使它变得更快、但实际上并没有。

我们将 STM32的堆栈大小增加到 BTPS 内核中定义的最大堆栈大小(在我们的情况下、堆栈大小从0x800增加到0x8000 = BTPS_configuration_PAN_disping_thread_stack_size)。 硬故障依然发生,地方也一样。

堆栈应该有多大? 硬件故障似乎是由 HCITR_COMDataCallback_UART 期间以及 HCILL_ReceiveBytes...之前的错误 RAM 地址引起的。 这两者之间在 Bluetopia 中做了什么?

谢谢你

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

    您是否在非操作系统或 RTOS 环境中使用? 您是否还打印了故障状态寄存器值?

    谢谢

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

    我们将非操作系统环境与自己的调度程序一起使用、调度程序在每个循环中首先调用 BTPS_ProcessScheduler (这是我们调用它的唯一位置)。

    这是我获得的故障报告:

    这是一个总线故障、故障地址为0x20018000、实际上是 RAM 的末尾... RAM 在映射文件中从0x20000000映射到0x2000F290。 Bluetopia 的堆从0x20003608映射到0x20008608 (我们已经增加了它、请确保)。 调用栈指示它正在 HCITR_COMDataCallback_UART 中运行。

    感谢您的快速回复!

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

    您是否可以尝试为测试禁用 HILL 和睡眠模式? 需要在 BTS 文件中更改这些内容、转换为*。h 文件并重新构建应用程序。

    谢谢

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

    我们已在.bts 文件中禁用睡眠( http://processors.wiki.ti.com/index.php/CC256x_Bluetooth_Hardware_Evaluation_Tool 中有注释)。 我不确定应该在.bts 中禁用 HILL 的位置... 您是使用"VS_Enable_SLEEP_Mode (BluetoothStackID、false)"禁用 HILL 睡眠吗?

    在附注中、我看到自12月以来有一个用于 CC256x (1.7)的新服务包。 我们使用了 SP 1.6、禁用睡眠功能。 我正在测试1.7、睡眠被禁用、只是为了看一下。

    谢谢你

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

    您好!

    我可以确认硬故障仍然发生、SP 1.7和.bts 文件中禁用睡眠、VS_Enable_SLEEP_Mode (BluetoothStackID、false)或 VS_Enable_SLEEP_Mode (BluetoothStackID、true)。

    我仍然看到 R3寄存器、其中包含 HCILL_ReceiveBytes()的起始地址、并且调用栈指示它位于 HCITR_COMDataCallback_UART ()...

    是否还有其他可能导致 Bluetopia 调用无效地址的东西? 如果 BLE 流量增加(如果我们向 SPPLE 发送命令并且 CC256发送更快的通知)、则硬故障发生得更快。。。

    谢谢你

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

    我仍然有这个问题。 感谢您的帮助...

    我尝试增加堆栈和堆大小、将服务包更新到最新版本1.7、并在 BTS 文件中禁用睡眠。 我仍然遇到硬故障。

    只需添加更多信息:

    我看到硬件故障的调用方代码位于 HCITR_COMDataCallback_UART()中 + 0x4B。

    示例

    在映射文件中:

    从图像符号表中提取

    符号名称 OV 类型 尺寸 对象(段)
    i.HCITR_COMDataCallback_UART 0x0803ac0c. 部分 0 HCIComM.o (i.HCITR_COMDataCallback_UART)
    HCITR_COMDataCallback_UART 0x0803ac0d Thumb 代码 470 HCIComM.o (i.HCITR_COMDataCallback_UART)


     
       

    对于此映射文件、硬故障调用方代码位于地址0x0803ac58。

    如果我在0x0803ac56上放置一个断点(只能在32位对齐的 mem 地址上放置断点)、我会看到代码执行时通常不会出现任何问题。 只有在 BLE 流量(双向)较高的几个小时后、我才会遇到"随机"硬故障。

    是否可以知道 在 HCITR_COMDataCallback_UART 中的这个特定地址执行了什么操作? 这可能有助于找到原因!

    谢谢!

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

    您好!  

    在进一步监控之后、我看到在硬故障之前分配了一个249字节的存储器(每次)。 与我们在正常运行期间看到的通常6到16字节相比、这是一个相当大的分配。

    分配在 HCITR_COMDataCallback_UART 中完成、而不是在我们的源代码中完成。 当硬故障 TRIG 时、Bluetopia 的存储器缓冲区甚至不是半满、我们在这之前没有看到存储器泄漏(使用的字节和 alloc 与 free 的数量的计数是稳定的)。  

    我使用 BLE 监听器进行了检查、只是为了查看它是否可能是一个巨大的 BLE 数据包或形式不良的 BLE 数据包、但什么都没有。 通知仅在硬故障时停止、但连接仍在以固定的连接间隔保留空数据包。

    我怀疑 HCITR_COMDataCallback_UART 中的分配大小可能会溢出... 分配的249个字节稍后将在 HCITR_COMDataCallback_UART 中使用(精确地说、在函数起始地址+ 0x4B 处)、从而触发硬故障。 我们将"Bluetopia_16_M4.fp_hw_fp.lib"与 Keil (rvmdk)搭配使用。  

    我们可以做些什么来解决这个问题?

    谢谢你

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

    我想知道、来自 UART 的任何非法 HCI 数据包是否会导致问题。 我建议如下:

    a)尝试、如果正在使用、则使用 UART 的 DMA。

    b)请参阅、如果可以监听主机和控制器之间的 UART 线。

    放置一个断点、如果分配大小为249 (您在所有崩溃之前提到过该值是一致的)、然后查看是否存在 UART、DAM 错误。

    谢谢

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

    我想知道、来自 UART 的任何非法 HCI 数据包是否会导致问题。 我建议如下:

    a)尝试、如果正在使用、则使用 UART 的 DMA。

    b)请参阅、如果可以监听主机和控制器之间的 UART 线。

    放置一个断点、如果分配大小为249 (您在所有崩溃之前提到过该值是一致的)、然后查看是否存在 UART、DAM 错误。

    谢谢