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
On a stm32wb55 based board with the rfcore (WS) firmware blob wiped / damaged.
from bluetooth import BLE
BLE().active(1)
Ends up stuck with tl_ble_wait_resp: timeout repeated on the command line every few seconds.
Expected behaviour
The tl_ble_wait_resp: timeout message is expected due to lack of response from the rfcore, however there is a timeout in C so this should only retry a limited number of times (2 seconds worth) before aborting with a Timeout error:
Instead, the tl_ble_wait_resp: timeout message repeats forever. On my application this cannot be ctrl-c interrupted, it reboots after some time only because we have a WDT running.
Additional Information
I've debugged the issue down to the scheduler, specifically the C STATIC_NODES section of it:
In this case the C scheduler is used to run mp_bluetooth_hci_poll(). Due to timeout trying to communicate with hci a ble_hs_reset() gets run on the nimble os_eventq which starts by resetting the hci transport.
That flows through to mp_bluetooth_hci_uart_init() which itself starts the hci polling...
This re-inserts the hci poll function into head of the c schedule linked list meaing it's ready to be run immediately, forming an infinite loop in mp_sched_run_pending()
Code of Conduct
Yes, I agree
The text was updated successfully, but these errors were encountered:
This is a bit of a trap with the C static scheduler; if the scheduled function itself triggers the scheduling of a c function it creates the infinite loop here.
@dpgeorge should the scheduler have a limit to the number of funtions processed in a single loop?
Or would it be enough / appropriate to document this limitation and just change the mp_bluetooth_hci_start_polling() implementation from mp_bluetooth_hci_poll_now() to a mp_bluetooth_hci_poll_in_ms(100)
Port, board and/or hardware
stm32wb55
MicroPython version
master branch, slightly newer than v1.25
Reproduction
On a stm32wb55 based board with the rfcore (WS) firmware blob wiped / damaged.
Ends up stuck with
tl_ble_wait_resp: timeout
repeated on the command line every few seconds.Expected behaviour
The
tl_ble_wait_resp: timeout
message is expected due to lack of response from the rfcore, however there is a timeout in C so this should only retry a limited number of times (2 seconds worth) before aborting with a Timeout error:micropython/extmod/nimble/modbluetooth_nimble.c
Line 632 in 79abdad
Observed behaviour
Instead, the
tl_ble_wait_resp: timeout
message repeats forever. On my application this cannot be ctrl-c interrupted, it reboots after some time only because we have a WDT running.Additional Information
I've debugged the issue down to the scheduler, specifically the C STATIC_NODES section of it:
In this case the C scheduler is used to run
mp_bluetooth_hci_poll()
. Due to timeout trying to communicate with hci able_hs_reset()
gets run on the nimble os_eventq which starts by resetting the hci transport.That flows through to mp_bluetooth_hci_uart_init() which itself starts the hci polling...
This re-inserts the hci poll function into head of the c schedule linked list meaing it's ready to be run immediately, forming an infinite loop in
mp_sched_run_pending()
Code of Conduct
Yes, I agree
The text was updated successfully, but these errors were encountered: