使用WRITE_TYPE_NO_RESPONSE发送许多数据包时,Android BLE连接中断

时间:2017-07-02 19:50:22

标签: android bluetooth-lowenergy file-transfer stm32f4

我对一个需要使用蓝牙LE从Android设备发送固件文件到STM32F4芯片的项目感到疯狂。

我已经成功地在两端实现了BLE,并且我在很长一段时间内使用它具有多种特性而没有任何问题。

现在应该实现一个文件传输,它应该能够发送大小约为250K的文件。我的实现似乎有效,但只有10个案例中的一个。它确实开始以20个字节的块发送数据包,然后发送它 在一个未确定的点上停止90%的测试用例的通信。我需要断开/重置并重新启动以重新启动。

STM32F4上的文件转换器的特性定义为:

 ret = aci_gatt_add_char(fileServiceHandle,
                            UUID_TYPE_128,                      // File xfer  UUID 
                            uuid,                               // Char UUID
                            FILEIO_RECORD_LEN,                  // Maximum length of the characteristic value (20)
                            CHAR_PROP_WRITE|CHAR_PROP_WRITE_WITHOUT_RESP|CHAR_PROP_NOTIFY,   // WRITE NOTIFY me
                            ATTR_PERMISSION_NONE,               // Nothing special
                            GATT_NOTIFY_ATTRIBUTE_WRITE,        // The application will be notified when a client writes to this attribute.
                                                                // An @ref EVT_BLUE_GATT_ATTRIBUTE_MODIFIED will be issued.
                            16,                                 // Encryption key size
                            0,                                  // is fixed length (1== variable size)
                            &fileRequestHandle);                // ReturnValue als handle

在Andoid中我将服务特性中的WRITE_TYPE_NO_RESPONSE标志设置为

public void onServicesDiscovered(BluetoothGatt gatt, int status) {
   ... aServiceCharacteristic.setWriteType(BluetoothGattCharacteristic.WRITE_TYPE_NO_RESPONSE);

写入数据包是在onCharacteristicWrite回调函数中完成的,最多可以包含8个数据包。

  • 最多可构建8个文件数据片段并将其排入fifo

  • wrtCharacteristic.setValue(firstQueueItem);

  • onCharacteristicWrite回复中的
  • if queue not empy { wrtCharacteristic.setValue(nextQueueItem);}

  • 如果在STM32F4中收到最后一个数据包,则验证该组中的所有数据包并发送一个确认消息,从而在APP中发生事件。 然后该事件触发发送接下来的8个数据包。

这对我来说非常直接,有时似乎有效。如果我将连续块的数量设置为1,它总是有效。在几乎所有情况下,所有其他大小都不能完成发送in文件。

没有证据表明传输何时被破坏,有时是在发送超过80%的数据后有时立即。

我还尝试跳过将STM32F4上的接收数据写入闪存存储器,以避免SPI干扰而不会改变行为。

这里有什么我想念的吗?我在哪里可以检查错误。任何帮助都会非常感激。

1 个答案:

答案 0 :(得分:0)

由于未知原因,此问题确实会再发生。与我在顶部所说的相比,我的实施没有改变。我试图为每个组的最后一个数据包请求BLE响应,但这似乎没有任何区别。

感谢阅读并评论此条目的所有人。