47d02b3104
If the _IRQ_L2CAP_RECV handler does the actual consumption of the incoming data (i.e. via l2cap_recvinto), rather than setting a flag for non-scheduler-context to handle it later, then two things can happen: - It can starve the VM (i.e. the scheduled task never terminates). This is because calling l2cap_recvinto will empty the rx buffer, which will grant more credits to the channel (an HCI command), meaning more data can arrive. This means that the loop in hal_uart.c that keeps reading HCI data from the uart and executing NimBLE events as they are created will not terminate, preventing other VM code from running. - There's no flow control (i.e. data will arrive too quickly). The channel shouldn't be given credits until after we return from scheduler context. It's preferable that no work is done in scheduler/IRQ context. But to prevent this being a problem this commit changes l2cap_recvinto so that if it is called in IRQ context, and the Python handler empties the rx buffer, then don't grant credits until the Python handler is complete. Signed-off-by: Jim Mussared <jim.mussared@gmail.com> |
||
|---|---|---|
| .. | ||
| bsp | ||
| hal | ||
| logcfg | ||
| nimble | ||
| syscfg | ||
| modbluetooth_nimble.c | ||
| modbluetooth_nimble.h | ||
| nimble.mk | ||