8000 BLE init failures can cause infinite loop in scheduler · Issue #17246 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content
8000

BLE init failures can cause infinite loop in scheduler #17246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
andrewleech opened this issue May 5, 2025 · 1 comment
Open

BLE init failures can cause infinite loop in scheduler #17246

andrewleech opened this issue May 5, 2025 · 1 comment
Labels
bug

Comments

@andrewleech
Copy link
Contributor

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.

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:

micropython/extmod/nimble/modbluetooth_nimble.c

Line 632 in 79abdad

mp_uint_t timeout_start_ticks_ms = mp_hal_ticks_ms();

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:

Image

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...

Image

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
@andrewleech andrewleech added the bug label May 5, 2025
@andrewleech
Copy link
Contributor Author
andrewleech commented May 5, 2025 •
edited
Loading

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)

This was referenced May 5, 2025
Open
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@andrewleech
0