This will conflict with #10739.

This will conflict with #10739.

Why would it ? Seems unrelated

Ah I see the cancel_alarm fix is there too! However I think it's documented better here, plus the switch to static node, I can rebase though if that PR is merged first.

@dpgeorge Note I found a maybe minor issue with the HCI UART config, the baudrate was set as a positional arg, when it actually should be a keyword arg. Also related note both port and baudrate were never used, which is fine, but doesn't allow HCI drivers to change baudrate to higher one (i.e secondary baudrate). I fixed those issues and forced pushed, still doing some tests with the help of @robert-hh, you can merge the other PR first and I'll rebase.

EDIT: Actually might be easier to just implement mp_bluetooth_hci_uart_set_baudrate

@dpgeorge @robert-hh Can we get these fixes merged especially the critical mpbthciport timer fix ? The other PR seems stalled and I would like to rebase some other work on those fixes.

@iabdalkader What can I do in this respect? I can re-run the tests. The code changes are well known to me and look fine. Did the test coverage increase with these changes?

The code changes are well known to me and look fine. Did the test coverage increase with these changes?

I didn't do any more testing since last time, will revisit after this is merged. Just wanted to let you know these fixes are still pending here since you're adding WiFi/BT for another port, might want to rebase on this.

Two notes:

• There is the PR number 2 to the mynewt-nimble lib, which prevents lock-up of the nimble stack in certain rare conditions.
• For using the nina_bt_hci.c driver with samd and mimxrt boards, I had to add code at the start of nina_hci_cmd() to clear the input buffer before sending a command. That was needed since the physical connection of the NINA module to the mcu was different.

since you're adding WiFi/BT for another port, might want to rebase on this.

Yes, this one and #10233. But I will add WiFi first. I'm still not overly happy with the BLE test coverage using the NINA module & software.

I'm still not overly happy with the BLE test coverage using the NINA module & software.

Yeah me neither but it seems that it's not an issue in the Nina module/driver/firmware. I have another board based on Renesas chip/port and an ESP32 module, the firmware is based on IDF 5.x and I added a nimble port, and the tests results are bad too:

18 tests performed
7 tests passed
1 tests skipped: multi_bluetooth/ble_deepsleep.py
10 tests failed: multi_bluetooth/ble_descriptor.py multi_bluetooth/ble_gap_advertise.py multi_bluetooth/ble_gap_connect.py multi_bluetooth/ble_gap_device_name.py multi_bluetooth/ble_gap_pair.py multi_bluetooth/ble_l2cap.py multi_bluetooth/ble_mtu.py multi_bluetooth/ble_mtu_peripheral.py multi_bluetooth/perf_l2cap.py multi_bluetooth/stress_log_filesystem.py

Note the firmware is an official firmware from espressif

@dpgeorge Rebased.