Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.46%. Comparing base (2dc2e30) to head (9c4e84f).
⚠️ Report is 3 commits behind head on master.

@@           Coverage Diff           @@
##           master    #8318   +/-   ##
=======================================
  Coverage   98.46%   98.46%           
=======================================
  Files         176      176           
  Lines       22784    22784           
=======================================
  Hits        22435    22435           
  Misses        349      349           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Now tested on nrf52840 dongle with the Adafruit UF2 bootloader: https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/download/0.6.3/pca10059_bootloader-0.6.3_s140_6.1.1.zip

Flashed that on with nrfutil following adafruit instructions

pipx install adafruit-nrfutil
adafruit-nrfutil --verbose dfu serial -p /dev/ttyACM0 -b 115200  --package pca10059_bootloader-0.6.3_s140_6.1.1.zip 

It reboots in mass storage mode.

While this bootloader comes with a copy of the softdevice bundled, micropython will happily flash over the top of that. Apparently the adafruit uf2 bootloader live checks if SD is installed and can work with/without it just fine - however no BLE OTA updates without it.

I compiled this current commit (fea9f0d) again with DFU=1 then converted the hex to uf2

#curl -L https://raw.githubusercontent.com/microsoft/uf2/master/utils/uf2conv.py > uf2conv.py
#curl -L https://raw.githubusercontent.com/microsoft/uf2/master/utils/uf2families.json > uf2families.json
#python uf2conv.py firmware.hex  -c -f 0xADA52840 -o nrf52840_micropython_ubluetooth_fea9f0d0.uf2
python tools/uf2conv.py ports/nrf/build-PCA10059/firmware.hex -c -f 0xADA52840 -o nrf52840_micropython_ubluetooth.uf2

nrf52840_micropython_ubluetooth_fea9f0d0.uf2.zip

Then drag and drop the uf2 onto the board bootloader.
It copies, then reboots with micropython running.

double click the reset switch to get back into bootloader.

Note that there is a copy of uf2conv.py in this repo, under tools/.

Ok, I've tried running the ble multitests... it didn't go great. Initially they all failed, found a few issues, fixed a few issues.
Currently, running with two nrf boards, I get 6 out of 30 tests failing still.

micropython/tests$ python run-multitests.py -i pyb:/dev/ttyACM1 -i pyb:/dev/ttyACM0 multi_bluetooth/*
...
30 tests performed
24 tests passed
6 tests failed: multi_bluetooth/ble_gap_pair.py multi_bluetooth/ble_gap_pair_bond.py multi_bluetooth/perf_gatt_char_write.py multi_bluetooth/perf_gatt_notify.py multi_bluetooth/perf_l2cap.py multi_bluetooth/stress_log_filesystem.py

I haven't looked into these failures specifically yet, other than the stress_log_filesystem which requires print(file=) kwarg, which requires MICROPY_PY_IO which needs fixes present in my (unfinished) #8317

So coming back to this, for some reason the previous approach to flashing adafruit uf2 bootloader on the nordic nrf52840 dongle won't work for me anymore. Pressing the right-angle button on the dongle puts it into bootloader mode, at which point I try:

pip install adafruit-nrfutil; adafruit-nrfutil --verbose dfu serial --package pca10059_bootloader-0.6.3_s140_6.1.1.zip -p COM39 -b 115200 --singlebank

Upgrading target on COM39 with DFU package pca10059_bootloader-0.6.3_s140_6.1.1.zip. Flow control is disabled, Single bank, Touch disabled
Opened serial port COM39
Starting DFU upgrade of type 3, SoftDevice size: 151016, bootloader size: 39000, application size: 0
Sending DFU start packet
Timed out waiting for acknowledgement from device.

Same deal running in linux, no change with newer pca10059_bootloader-0.7.0_s140_6.1.1.zip. nordic's nrfutil can't handle adafruit's zip file because they've added newer keys (dfu_version) to the metadata in it.

So downloaded the hex of the bootloader instead and convert it:

nrfutil pkg generate --hw-version 52 --sd-req 0 --application pca10059_bootloader-0.7.0_s140_6.1.1.hex --application-version-string "0.7.0" dfu.zip

Then try to flash it

nrfutil.exe dfu serial -pkg dfu.zip -p COM4 -b 115200

Traceback (most recent call last):
<snip>
  File "nordicsemi\dfu\dfu_transport_serial.py", line 256, in send_init_packet
  File "nordicsemi\dfu\dfu_transport_serial.py", line 421, in __execute
  File "nordicsemi\dfu\dfu_transport_serial.py", line 505, in __get_response
pc_ble_driver_py.exceptions.NordicSemiException: Response Code InsufficientResources

So yeah, I gave up on adafruit and uf2 bootloader.

pip uninstall adafruit-nrfutil  # they conflct / cannot co-exist
pip install nrfutil
cd ports/nrf
make BOARD=pca10059 FLASHER=nrfutil deploy

that works! ok, back to testing multi_bluetooth tests...

Code size report:

Reference:  tools/ci.sh: Increase qemu_arm test run timeout. [5c00edc]
Comparison: nrf/bluetooth: Add support for nimble based ubluetooth. [merge of db0ea97]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.

It seems most multitests are unreliable, occasionally failing with a timeout.
Other tests fail pretty much every time.
So there's something not right with the integration so far.
I just tried replacing my ticker use for hci poll with pendsv and soft timer like other ports but that doesn't seem to have helped.

It seems most multitests are unreliable, occasionally failing with a timeout.
Other tests fail pretty much every time.

I had noticed that when adapting the NINAW10 package for the SAMD and MIMXRT port. Some tests fail always, some tests fail never, some sometimes. Using the ESP_HOSTED package is much more reliable, even if both rely on nimble. With ESP_HOSTED still some tests fail nearly always (like deepsleep and stress_log_filesystem, but the other tests pass fine. The list below shows the success rate with the NINAW10 package of 100 attempts.

77 ble_characteristic
100 ble_gap_advertise
100 ble_gap_connect
63 ble_gap_device_name
40 ble_gap_pair_bond
54 ble_gap_pair
55 ble_gattc_discover_services
63 ble_gatt_data_transfer
83 ble_l2cap
0 ble_mtu
57 ble_subscribe
94 perf_gatt_char_write
58 perf_gatt_notify
58 perf_l2cap

That's really interesting. The tests I was having issues with seemed fine going from pyb-d to stm32wb55 so it's definitely the nrf that's got issues compared to them.

I did some more testing and suspect my soft timer integration might not be working, I'll want to get a debugger connected to check what it's actually doing.

For me, the BLE multitests are very robust when testing using PYBD-SFx and ESP32 boards, which use NimBLE. Maybe occasionally one of them will fail, but it's not often.

There are no problems in testing with PYBD or ESP32. Since both NINAW10 and ESP_HOSTED use the ESP32 implementation of BLE, but with a different version of the ESP_IDF (3.x vs. 5.x), it looks like that make the difference.

I've rebased this to current master but haven't yet re-tested anything