Request of some advice to solve lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)

[asukiaaa]

I tried to connect esp32 with xbox controller it again but failed with the following error.

lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
E NimBLEClient: "Connection failed; status=574 "

The code (pClient->connect(true);) which causes the error.
https://github.com/asukiaaa/arduino-XboxControllerNotificationParser/blob/a0cf4052ee305cd6dfaf28cbf9c5c03044400d66/examples/printOnSerialWithNimBLE/printOnSerialWithNimBLE.ino#L248

I succeeded in it with your help before.
#172

My environment of PlatformIO

NimBLE: 1.3.1

PLATFORM: Espressif 32 (3.3.2) > Espressif ESP32 Dev Module
 - framework-arduinoespressif32 3.10006.210326 (1.0.6) 
 - tool-esptoolpy 1.30100.210531 (3.1.0) 
 - tool-mkspiffs 2.230.0 (2.30) 
 - toolchain-xtensa32 2.50200.97 (5.2.0)

I rollbacked the versions as begin of this year but it also failed.

E NimBLEClient: "Connection failed; status=574 "

NimBLE: 1.1.0

PLATFORM: Espressif 32 (3.0.0) > Espressif ESP32 Dev Module
 - framework-arduinoespressif32 3.10004.210126 (1.0.4) 
 - tool-esptoolpy 1.30000.201119 (3.0.0) 
 - tool-mkspiffs 2.230.0 (2.30) 
 - toolchain-xtensa32 2.50200.97 (5.2.0)

Could you give me some advice to solve this?
Thank you.

[h2zero]

Please try removing the connection parameter setting at line 230 in your code and let me know if that has more success.

[asukiaaa]

@h2zero
Thank you for the advice.
I comment out line 230.

    // pClient->setConnectionParams(12, 12, 0, 51);

After that it sometimes succeeded in connection but causes panic after that.

New client created
lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
E NimBLEClient: "Connection failed; status=574 "
try connection again 2650
lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
E NimBLEClient: "Connection failed; status=574 "
try connection again 4460
Connected
Connected to: 44:16:22:5e:b2:d4
RSSI: -42
E NimBLERemoteCharacteristic: "ble_gattc_disc_all_dscs: rc=3 "
E NimBLERemoteCharacteristic: "Error: Failed to get descriptors"
E NimBLERemoteCharacteristic: "ble_gattc_disc_all_dscs: rc=3 "
E NimBLERemoteCharacteristic: "Error: Failed to get descriptors"
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x400d4f0f  PS      : 0x00060b30  A0      : 0x800d4f81  A1      : 0x3ffc6640  
A2      : 0x3ffc94e0  A3      : 0x00000000  A4      : 0x00000000  A5      : 0x00000000  
A6      : 0x00ff0000  A7      : 0x00000005  A8      : 0xfffffffc  A9      : 0x00000000  
A10     : 0x00000001  A11     : 0x00000001  A12     : 0x00000008  A13     : 0x400d5198  
A14     : 0x3ffc6640  A15     : 0x3ffc1f2c  SAR     : 0x00000018  EXCCAUSE: 0x0000001c  
EXCVADDR: 0xfffffffc  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

ELF file SHA256: 0000000000000000

Backtrace: 0x400d4f0f:0x3ffc6640 0x400d4f7e:0x3ffc6670 0x400d3b46:0x3ffc6690 0x400d20c5:0x3ffc66b0 0x400d223f:0x3ffc6700 0x400e8375:0x3ffc6720 0x4008fea2:0x3ffc6740

Rebooting...

[h2zero]

Thank you for reporting this, I see there is a bug in that section of the code that I will try to get fixed later today.

For a work around I suggest not using the discoverAttributes function, your afterconnect function should do that for you anyway.

[asukiaaa]

I see there is a bug in that section of the code that I will try to get fixed later today.

Thank you,
I hope that you can fix this.

I suggest not using the discoverAttributes function,

Thank you for checking the code.
I commented out it.

[visicon-masc]

Hi!
Is this issue resolved? I have here a lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) issue with "Nimle-Client.ino" talking to "Nimble_Server.ino" examples. Scenario is: connection established, then i reboot the server:

This runs with just slidely modofied examples (removed the "DEAD" service on client side and add an upcounting integer to send for characteristic "F00d" on server side, thats all).

Nimble 1.3.1, arduino-esp32 2.0.0

Thanks in advance, bye, Marc.

[h2zero]

@visicon-masc that message is a controller debug message indicating some packets were received that were not expected. This is basically reporting packet loss so the connection was not completed. There isn't much we can do about that as the causes are mostly external and the BLE controller is a closed binary source on the ESP32.

The bug reported in this thread is due to another cause that I have not had time to address yet, but the log message is not indicative of that.

[asukiaaa]

I tried with the latest version platforms.
The error still occurs but sometimes it succeeded in connection with xbox controller and can see the notification.

Platforms

• PlatformIO 5.2.3
• NimBLE 1.3.1
• esp32

Platform espressif32
--------
Updating platformio/espressif32               3.4.0                              [Up-to-date]
Updating platformio/toolchain-xtensa32        2.50200.97 @ ~2.50200.0            [Up-to-date]
Updating platformio/framework-arduinoespressif32 3.10006.210326 @ ~3.10006.0        [Up-to-date]
Updating platformio/tool-esptoolpy            1.30100.210531 @ ~1.30100.0        [Up-to-date]
Updating platformio/tool-mkspiffs             2.230.0 @ ~2.230.0                 [Up-to-date]

Thank you.

[asukiaaa]

The issue maybe caused by process in esp-idf.
espressif/esp-idf#8303
So I close the issue on this library.

The log I got.

lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
D NimBLEClient: Got Client event 
E NimBLEClient: Connection failed; status=574 
D NimBLEClient: >> connect(44:16:22:5e:b2:d4)
D NimBLEClient: Got Client event 
I NimBLEClient: Connected event
lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
D NimBLEClient: Got Client event 
E NimBLEClient: Connection failed; status=574 
D NimBLEClient: >> connect(44:16:22:5e:b2:d4)
D NimBLEClient: Got Client event 
I NimBLEClient: Connected event

NimBLE 1.3.6
platformio-esp32: 3.5.0 (esp-idf: 4.3.2)

[asukiaaa]

I traced timing of lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) and found that it is showed between calling ble_hs_hci_rx_evt.
The ble_hs_hci_rx_evt is registered by ble_hci_trans_cfg_hs.

NimBLE-Arduino/src/nimble/nimble/host/src/ble_hs.c

Line 802 in 26e0130

ble_hci_trans_cfg_hs(ble_hs_hci_rx_evt, NULL, ble_hs_rx_data, NULL);

The ble_hci_trans_cfg_hs is defined in eps-idf for nimble.
https://github.com/espressif/esp-idf/blob/5c33570524118873f7bd32490c7a0442fede4bf8/components/bt/host/nimble/esp-hci/src/esp_nimble_hci.c#L57

I have to setup environment to debug esp-idf so I finish here today.

[h2zero]

I would advise not spending too much time digging into this.

lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) is printed by the controller which is a closed source binary.

The error that's occurring is a timeout on the connection, which can be caused by many things. NimBLE host code simply sends the command to the controller and waits for its response. If the packets arrive out of sync the controller prints that message and returns the error code.

A short list of possible causes:

• radio interference
• low voltage
• controller interrupted
• poor timing control
• controller source code bug

If you're inclined to dig deeper I'm all for it but I suspect you'll hit a road block at the controller or hardware level.

For reference this library has its own copy of the esp_nimble_hci.c file.

[asukiaaa]

Thank you for the information.
I understood that the error may be returned by arriving packet at out of sync and it may be a problem of closed source library or hardware level.
Anyway I will dig esp-idf if I can keep interest to do that.

By the way, how about this PR?
#343

[asukiaaa]

Note
Cleaning before building sometimes solves the problem.

Cleaning command on platform io

pio run -t clean

[distancerunner]

lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) is printed by the controller which is a closed source binary.

My ESP32 stops working, if this message occuring. Is there a possibility to restart the ESP if this message is sent from the bt controller?

[asukiaaa]

On my case, the error occurs on ESP32, but doesn't on ESP32S3 and ESP32C3.
I doubt some problem on IC.

The problem is discussed on esp-idf thread espressif/esp-idf#8303 but it is still unresolved.

[distancerunner]

Nope. Its depending on the code. But I was stupid and missed something.

      Serial.println("We have failed to connect to the server; there is nothing more we will do."); ```

In all examples, there is this if statement in the loop(). There I now added a procedure for reconnecting, after this HCI error.

I had no HCI error for days (I think it is an timing error while establishing the connection). Today I speed up my code and connection routine, and this error occurred. 
Maybe my BLE controller is to slow in some situations.