我對需要使用藍牙LE將Android設備的固件文件發送到STM32F4芯片的項目感到很頭疼。使用WRITE_TYPE_NO_RESPONSE發送多個數據包時Android BLE連接中斷
我已經在兩端都成功實施了BLE,並且我正在使用它具有幾個特性很長一段時間沒有任何問題。
現在文件傳輸應該能夠發送大小約爲250K的文件。我的實施似乎有效,但只有10個案例中的一個。它確實開始以20個字節爲單位發送數據包,但它在未確定的點上停止90%的測試用例的通信。我需要斷開/重置並重新啓動才能重新啓動。
特性有關STM32F4文件transger被定義爲:
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個數據包的FIFO進行回調函數。
累積到文件中的數據的8個片段,並將其排隊中onCharacteristicWrite呼叫一個FIFO
wrtCharacteristic.setValue(firstQueueItem);
回:如果接收到的最後分組
if queue not empy { wrtCharacteristic.setValue(nextQueueItem);
}在STM32F4中,該組中的所有數據包都經過驗證,並且發回一個確認信息,從而在APP中引發一個事件。 該事件然後觸發發送接下來的8個數據包。
這看起來很直截了當,似乎有時工作。如果我將連續塊的數量設置爲1,它總是有效。所有其他大小在幾乎所有情況下都不會完成發送文件。
沒有證據表明傳輸何時中斷,有時甚至在發送超過80%的數據後立即發生。
我也嘗試跳過將接收到的STM32F4數據寫入閃存存儲器,以避免SPI干擾而沒有任何行爲改變。
有什麼我在這裏失蹤?我在哪裏可以檢查錯誤。任何幫助將非常感激。
你在哪裏調用'writeCharacteristic'? – Emil
writeCharacteristic總是跟在setValue之後,並且只有在前面的任何寫操作完成時才被調用。 我也嘗試過'setWriteType(BluetoothGattCharacteristic.WRITE_TYPE_DEFAULT);'但沒有成功。 –
您應該檢查Android中的Bluetooth hci日誌或嗅探器跟蹤來查看真正發生的事情。 – Emil