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.

[参考译文] RTOS/CC2640:WFI (等待中断)在多角色器件中挂起

Guru**** 2587445 points
Other Parts Discussed in Thread: CC2650, SYSBIOS

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/598685/rtos-cc2640-wfi-wait-for-interrupt-hang-in-multi-role-device

器件型号:CC2640
Thread 中讨论的其他器件:CC2650SYSBIOS

工具/软件:TI-RTOS

我遇到固件卡在 WFI 指令中的问题(ARM 等待中断)。

当器件被重新连接至调试器时、它会正确地移动到下一条指令并更新时钟、尽管它们显然都是错误的(即、超过了它们应该在上面过期的节拍)。

在论坛中阅读、这种情况的唯一可能发生方式是、如果在调用任何 WFI 指令之前中断已经被暂停。  我们的电路板非常简单、没有外部外设、问题也出现在 SensorTag 上。

所有堆栈、堆、ICALL 资源都正常、ROV 中没有超限和错误。

在 RTOS 源树(tirtos_cc13xx_cc26xx_2_20_01_08)中进行搜索我唯一可以找到明确引用 WFI 指令的位置的位置是电源管理代码中、特别是对于我们来说、在 STANDBY 函数中。

编译器版本似乎没有太大的差异、但我们按照文档中的说明进行操作、我们的 BLE 堆栈(2_02_01_18)正在使用5.2.6进行编译、该应用本身具有15.12.5.LTS。

我已经用一个尝试调试这个问题的定制函数替代了待机函数、但我真的不知道我在寻找什么-是否有一种方法可以测试中断是否被禁用、所以我可以跳过 WFI 指令直到下次我 处于空闲循环中、希望它会复位?  调试非常困难(或者生成一个简单的程序来重新生成它)。

其他人对 WFI 指令可能生成的其他位置有任何见解、因此我可以对其进行检测?

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

    好的、那么我们可能会受到此线程中出现的错误的影响:

    但是、更改 RTOS 以增加超时值(请参阅线程)并重新编译它(以及设置 NO_ROM)并放置自定义电源处理函数未修复它。  重新连接到调试器时、系统仍然停留在地址0x10003298 (调试器导致前面的 WFI 指令解锁)。  我不知道0x10003298处的代码来自何处、它不是由堆栈或应用生成的地址、因此我只是假设它映射到 CC2650上的 ROM。

    在我看来、蓝牙堆栈项目本身直接调用 CPU 睡眠函数、而不是使用 RTOS 空闲。  观察构建、似乎可以设置一些标志来强制蓝牙堆栈使用 RTOS (因此、具有不同计时器设置的 RTOS 的修改版本)。  我们目前正在测试这一点、因为应用级代码肯定会使用 RTOS 的修改版本、但蓝牙堆栈似乎仍在使用 ROM 例程。

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

    是的、0x1000xxxx 地址与 ROM 匹配。 您可以从 TI-RTOS SDK 加载 RTOS 符号:
    C:\ti_tirtos_cc13xx_cc26xx_2_20_01_08\products\BIOS_6_46_01_38\packages/ti\SysBIOS\rom\cortexm\ccc26xx\golde\CC26xx

    此外、BLE 堆栈不会调用任何电源管理睡眠 API -这是由 RTOS 中的电源驱动程序在没有计划的 RTOS 活动时处理的。 换言之、当空闲任务能够运行时、电源驱动器将根据电源策略并在没有设置限制的情况下进入待机状态。 更多详细信息、请参阅 TI-RTOS 中的电源管理文档。

    除此之外、您能否提供更具体的步骤在 TI CC2650 LaunchPad 上重现此问题? 您是否正在使用 GitHub 提供的最新多角色示例应用?

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

    感谢 JXS 的回复。

    在我看来、除非您明确指定要调用 RTOS、否则开箱即用版本的 BLE 堆栈会直接调用电源管理-除非我们使用额外的重新编译 BLE 堆栈、否则无法始终如一地调用我们的自定义电源管理函数 预定义符号 OSAL_PORT2TIRTOS、并修复了执行该操作导致的一些小问题。

    但是、我认为我们确实解决了这个问题、这涉及到一个非常愚蠢的错误、我们在上下文切换中使用了一个任务的 GAP 角色、但使用了另一个任务的任务 ID。  我们已修复了该误差、器件更稳定。  我们发现它的唯一方法是偶然的-将应用时钟从静态更改为动态仍然会导致崩溃、但在不同的位置、这使我们相信我们正在研究某种类型的内存损坏问题。

    现在我要把这个标记为已解决、当我有更多的时间时、我会尝试构建一个最小崩溃的系统、但不幸的是、这是一件非常复杂的事情。  如果有人读取该线程并像这样随机崩溃、 最好的建议可能是非常好地查看进出 BLE 堆栈的所有代码、并确保特定任务对 GAPRole 函数的调用与您传递的"selfEntity"变量一致。  我对 RTOS 上下文切换程序的工作方式并不了解、但看起来执行类似操作会起作用、但非常不稳定。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    很高兴它能正常工作,David。 我怀疑有一个死锁、这可能会解释错误路由的 GAP 自实体任务 ID。

    祝你一切顺利