Queue filling in notify_host_recv

[richo]

Hi,

I created a bluetooth scale using esp-wifi in ble mode, however over time the messages in the BT_RECEIVE_QUEUE in btdm.rs aren't cleared, and so it begins to drop packets.

I'm not exactly sure how this condition can exist (I narrowed it down with some printf debugging) because I can't find any way to look at those packets that isn't a call to dequeue. My code is basically a hacked up version of the ble example for esp32. I'm happy to do whatever legwork to track this down, although I'm a little unclear on what could cause this or next steps.

So far, I've logged the size of the queue whenever a new packet is ingested and at face value it appears that once the scale actually starts receiving messages is when the issue manifests. The first few when it begins advertising appear to be removed from the queue correctly.

[bjoernQ]

I can only imagine the code isn't calling do_work or do_work_with_notification frequently enough.
If your code is open-source you could share it here - otherwise a minimal example to reproduce the issue would be helpful.

[richo]

Ah that would likely explain it! The example I cribbed from calls do_work_with_notification but never calls do_work. I will try that and report back.

Thankyou

[richo]

That appears to have fixed it! Thankyou!

Would you be interested in a PR that either includes "Are you calling do_work?" in that warning for the full queue, or at least one that makes the errors unique so I knew which stack was having the issue?

[bjoernQ]

Great to hear it's working for you now

Would you be interested in a PR that either includes "Are you calling do_work?" in that warning for the full queue, or at least one that makes the errors unique so I knew which stack was having the issue?

That's a bit of a problem since esp-wifi doesn't really care about the BLE stack used. In the examples we use the bleps stack - mostly because currently there isn't another pure Rust BLE-stack but users are free to use whatever they want (e.g. a stack implemented in C or some don't even use any stack and handle the HCI BLE commands in their own code)

[richo]

Ah sorry, I might have used the wrong terminology. My journey began with seeing the WARN in the output, but that exact warning appears in a few places:

https://github.com/esp-rs/esp-wifi/blob/16afb0fe3c46e2ccf698bf52bfec5230ffad1cad/esp-wifi/src/ble/btdm.rs#L92
https://github.com/esp-rs/esp-wifi/blob/16afb0fe3c46e2ccf698bf52bfec5230ffad1cad/esp-wifi/src/ble/npl.rs#L1217

So my thinking was that disambiguating them might be helpful (The first thing I did was put the function names in and rebuild like that).

[bjoernQ]

Ah I see - all chips before ESP32-C2 use btdm while all chips starting with ESP32-C2 use npl
But giving a hint which is in use might be helpful