You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background
Mbed boards (nano33ble, portentaH7) running ArduinoBLE have two relevant concurrent threads in execution: one executes the main arduino sketch, the other one handles the transport of HCI packets and stores the received ones in an internal buffer.
The thread executing the sketch should regularly call the BLE.poll() function to retrieve and analyze the packets stored by the other thread.
Problem:
If too much time passes between calls to the BLE.poll() function, then the buffer of received packets may become full. If it becomes full then the new packets received will be dropped. (see code)
This behaviour may result in a buffer overflow and consequently in a system crash.
Possible solutions
Discourage the use of blocking functions (delay(millis) should be avoided. An alternative BLE.delay() that calls BLE.poll() could be implemented)
Handle packets drop to prevent buffer overflows
Increase the reception buffer to increase reliability in case some blocking function is essential.
Stop the controller until some space is freed from the buffer (see #96)
Hi @polldo,
the changes in HCICordioTransport.cpp (#96) seem to fix my problem (#126) with hanging arduino when many BLE devices are nearby. I've succesfully tested it with 32 devices.
Background
Mbed boards (nano33ble, portentaH7) running ArduinoBLE have two relevant concurrent threads in execution: one executes the main arduino sketch, the other one handles the transport of HCI packets and stores the received ones in an internal buffer.
The thread executing the sketch should regularly call the
BLE.poll()
function to retrieve and analyze the packets stored by the other thread.Problem:
If too much time passes between calls to the
BLE.poll()
function, then the buffer of received packets may become full. If it becomes full then the new packets received will be dropped. (see code)This behaviour may result in a buffer overflow and consequently in a system crash.
Possible solutions
delay(millis)
should be avoided. An alternativeBLE.delay()
that callsBLE.poll()
could be implemented)Related issues
#126
#73
#102
The text was updated successfully, but these errors were encountered: