[参考译文] CC2340R5：蓝牙会导致线程无法正常工作

您好、Jan

测试后发现、如果连接不成功、但我调用了断开功能、似乎会引起问题。 或者、如果我开始扫描并在暂停扫描之前再次调用开始扫描、则似乎存在问题。 我想确认这是否导致我的线程出现问题？

Ryan、您好！

我可以问您如何验证是否已建立连接或断开连接？ 您使用的是由处理程序回调函数触发的 BLEAPPUTIL_LINK_ISTERNATED_EVENT 还是 BLEAPPUTIL_LINK_Terminated_EVENT？

BR.

David。

您好、David

我测试并发现、当我调用 BLEAppUtil_invokeFunctionNoData 来使线程消失时、TTT 将不等于11、这意味着它在执行 BLEAppUtil_enqueueMsg 后崩溃。

我认为它与连接无关、因为当我调用"开始扫描"和"停止扫描"时会出现此问题。

Ryan、您好！

我认为问题可能是我们没有在 iCall ()中注册新线程。 ICall BLE-Stack 服务用作 BLE-Stack API 的应用接口。 当应用程序在内部调用 BLE-Stack API 时、ICall 模块会将命令路由到堆栈、并在适当时将消息从堆栈路由到应用程序。 请查看用户指南中关于如何 ICall 注册 task：https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.10.00.55/exports/docs/ble5stack/ble_user_guide/html/freertos/tasks.html?highlight=icall%20register#creating-additional-icall-enabled-tasks 的这一部分。 但是如果情况不是这样、我预计会出现不同的错误、例如 ICall 中止。

BR.

David。

您好、David

在今天的测试之后、我发现这似乎是因为 UART_writeMode 设置为阻塞模式。 在调用大多数蓝牙函数之前、我将使用 UART 传输扫描或连接等的当前阶段 如果我在调用蓝牙后立即调用 UART2_WRITE、则耳塞的函数似乎会引起问题。 我测试了将 writeMode 更改为非阻塞模式。 到目前为止、测试运行正常。 此部件能否帮助我确认？  这是否与您所说的不在 iCall()中注册新线程有关?

Ryan、您好！

好的、我明白了。 您能否请看一下该主题中的最后一个答案、我认为这些答案可以作为测试(与任务优先级相关)的良好起点：https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1405164/lp-em-cc2340r5-can-uart2_write-and-uart2_read-not-be-used-in-the-same-task/5417015#5417015。此外、如果使用非阻塞模式、请确保您的应用具有正确的缓冲区大小、我想您现在已经认为它按预期工作了。

如果问题与非寄存器任务有关、我预计会出现与 ICall 中止相关的错误。

BR、

David。

尊敬的 David：

1.根据这篇文章,你是说 UART 中断优先级设置得较低,所以 CC2340 UART 线程就会消失?  


2.如果将 UART 写模式设置为非块、那么是否还需要增加 TX 环形缓冲区的大小？

3.iCall_abort ()也发生在我当时,但当时我认为这是因为我没有使用 BLEAppUtil_invokeFunctionNoData ()调用蓝牙相关函数。

Ryan、您好！

它认为这是任务优先级、而不是 UART 中断优先级。 仅当您目前没有接收到全部数据量时、才需要增加环形缓冲区的大小。

BR、

David