• 状态 Resolved
  • 已锁定 已锁定
  • 回复 4 回复
  • 订户 0 订户
  • 视图 427 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2640R2F：BLE 观测器角色在 SPI_transfer 结束调用后停止工作

admin
Guru**** 2553260 points
Other Parts Discussed in Thread: BLE-STACK, CC2640R2F, CC2640

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/576258/cc2640r2f-ble-observer-role-stops-working-after-spi_transfer-ends-callaback

器件型号：CC2640R2F
主题中讨论的其他器件： CC2640

您好！

( 适用于 CC2640R2、CCSv7的 BLE-Stack v3.0)

我们正在实施 BLE CC2640R2F 观测器器件、该器件正在扫描器件并过滤其器件名称。 当发现一个具有等待器件名称的广播器件时、它正在读取其 RSSI 值并通过 SPI 将其发送到 PCB 上的另一个 MCU。 CC2640R2F 通过将引脚设置为1 (Board_BLE_SPI_READY 引脚)来告知 MCU 何时准备好通过 SPI 传输 RSSI

我们一开始尝试在 simple_observer．c/SimpleBLEObserver．c_processRoleEvent ()/gap_device_discovery_event case 中启动 SPI_transfer，但在首次 SPI 传输后，BLE 观测  器不会再次进入 GAP_DEVICE_DISCOVERY 事件。

在 E2E 线程中的设置之后、我们决定在另一个 TI-RTOS 任务中实现 SPI_TRANSFERT：simple_spi.c. 但我们也有同样的问题：在发生 SPI_Transfer 后、BLE 观测器角色不再触发 GAP_DEVICE_DISCOVERY_EVENT 事件。

请查找随附的 CCS 工程导出。

e2e.ti.com/.../toy_5F00_source_5F00_code.zip

因此、问题是、在 SPI 传输发生后、BLE 观测器角色似乎没有被卡住、这是否正常。

此致、

Jérôme μ A

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

    您好！

    我还尝试使用 SPI_transger 的阻塞模式：

    e2e.ti.com/.../simple_5F00_spi.c

    在第一 个 GAP_DEVICE_DISCOVERY 事件之后、SPI 任务接收要通过邮箱发送的数据、SPI_TRANSFRAY 成功、状态为"SPI_TRANSFER_END"。

    但症状是相同的：永远不会再次调用 SimpleBLEObserver 事件 CB 回调、  也不会再次触发 GAP_DEVICE_DISCOVERY 事件、程序将在  简单观测器任务主循环的 Event_pend ()和观测器角色任务主循环的 Event_pend ()上挂起。

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

    您好！
    我认为 BLE 发现可能不应在 GAP_DEVICE_DISCOVERY 中重新启动、而应在 SPI 传输结束时重新启动。
    因此、我测试了另外两种解决方案、最终发现其中一种有效：
    *解决方案3 (不起作用)：仍在专用任务中执行 SPI 传输、在 SPI 传输结束回调中调用 SimpleBLE 任务的函数、该函数将对消息进行排队、以便 SimpleBLE 任务开始新的 BLE 发现。
    *解决方案4 (有效)：由于解决方案3不起作用、我尝试执行相同的操作、但没有专用的 SPI 传输任务。 SPI 传输在 GAP_DEVICE_DISCOVERY 事件中启动。 SPI 传输结束回调在队列中发布消息。 当消息被 SimpleBLE 主循环解出队列时、BLE 发现会重新启动。

    请查找这两种解决方案的源代码： e2e.ti.com/.../solution3_5F00_and4.zip

    我仍然不明白解决方案3为何不起作用、也不明白为什么 在启动 SPI 传输后重新启动 GAP_DEVICE_DISCOVERY 事件中的 BLE 发现、而不是在 SPI 传输结束回调中重新启动。

    您有没有解释给我吗？

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

    我找到了我们问题的解决方案。

    最后 、NFC 发现是在 SPI_transfer 开始后直接在 GAP_DEVICE_DISCOVERY 中启动还是在 SPI transfer 的回调中启动、这无关紧要。

    问题出在 SPI 传输本身。 SPI 总线另一端的 MCU 正在 MOSI 线路上的字节1至4上发送非零数据(从器件为 TI CC2640R2)。 我在 TI CC2640R2中分配了一个大小为1的 TX 缓冲器、因此我想它会在 CC2640R2上引发分段故障。

    正在工作的 SPI 传输：

    引发 TI CC2640故障的 SPI 传输：

  • 0
    TI__Guru**** 2553260 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    很高兴看到你找到了它！

    祝你一切顺利