BLE advertisements once cached are unchangable

[bodangly]

I am using a WiPy 3.0 with the latest firmware 1.20.2.r6 and once I have ran some code with BLE characteristics advertised, it is impossible to change them. I even tried reflashing firmware and clearing CONFIG and NVS partitions, but that did not help, they are stuck at an earlier version of my code.

# Set up bluetooth server
        bluetooth = Bluetooth()
        bluetooth.init(modem_sleep=False)
        name = "%s %s" % (DOOR_TABLET_ADVERTISEMENT, BLE_MAC.decode())
        bluetooth.set_advertisement(name=name, service_uuid=DOOR_TABLET_SERVICE_UUID)
        bluetooth.callback(trigger=Bluetooth.CLIENT_CONNECTED | Bluetooth.CLIENT_DISCONNECTED, handler=ble_connection_callback)
        bluetooth.advertise(True)

        schedule_service = bluetooth.service(uuid=SCHEDULE_SERVICE, isprimary=True, nbr_chars=4)
        schedule_bytes = bytearray()

        schedule_start_char = schedule_service.characteristic(uuid=SCHEDULE_START_CHAR, value=0)
        schedule_end_char = schedule_service.characteristic(uuid=SCHEDULE_END_CHAR, value=0)
        schedule_write_char = schedule_service.characteristic(uuid=SCHEDULE_WRITE_CHAR, value=0)
        deep_sleep_char = schedule_service.characteristic(uuid=DEEPSLEEP_CHAR, value=0)

I first had just the three characteristics, then added the deep_sleep_char, and the WiPy won't advertise it.

[Xykon]

Have you tried running Bluetooth().nvram_erase()

[scath999]

Having the same issue on a GPy.

1) Had a single BLE service with 6 characteristics running off of an nRF52840 communicating with a GPy. This worked. 2) Tried added two characteristics; GPy could see one but not both. 3) Then tried creating an entirely different service; GPy didn't see the new advertised service UUID, but did see the old one. "nRF Connect" (BLE Scanning App) saw the new service UUID. 4) Then tried commenting out all usage of the original service; GPy continued to see UUID of the first service. 5) Then tried restoring code to working backup from Step 1; GPy now finds a characteristic from step 2 that I'm no longer offering.

Bluetooth().nvram_erase() has not solved this issue. Re-Uploading code to GPy does not solve this issue.

Expected Result:

• GPy (and FiPy) recognizes different service UUIDs upon connection and handles them appropriately

Actual Result:

• GPy (and possibly FiPy) uses stored UUIDs associated with a known device and presumes they are still valid.

Note: This "caching" behavior persists even after power to GPy is cut. This is welcome in many circumstances, and I understand why it's part of the build, but I need to be able to expand the number of BLE services and characteristics dynamically as I develop.

[geza-pycom]

I experienced the same behavior with esp-idf 3.3.1, but not with esp-idf 4.x.

On 3.3.1 there is an API which shall solve this issue, _esp_ble_gattc_cacherefresh(), however using it resulted another error which happened sometimes, that an upcoming esp_ble_gattc_search_service() went into deadlock. Maybe could you please try adding _esp_ble_gattc_cacherefresh() before esp_ble_gattc_search_service() is called and check the result (in modbt.c)?

[scath999]

Hi @geza-pycom,

Thanks for the reply. I'm using Pycom's fork of Micropython. I'm not sure if or how I can make C calls.

Please advise.