Application service UUID gone after secure OTA DFU

RE: Application service UUID gone after secure OTA DFU

SK — Fri, 03 Jan 2020 08:54:30 GMT

Okay so i noticed that for the previous SDK 14.2 i used inactivity timer value as 10000.

Increasing the value to 120000 as was default, i did not see any GATT error while doing OTA DFU.

RE: Application service UUID gone after secure OTA DFU

SK — Fri, 03 Jan 2020 07:20:48 GMT

logs from the bootloader as i try to do DFU

<debug> app: In nrf_bootloader_init

<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...

<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.

<debug> nrf_dfu_settings: Using settings page.

<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Enter nrf_bootloader_fw_activate

<info> app: No firmware to activate.

<debug> app: App is valid

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Running nrf_bootloader_app_start with address: 0x00001000

<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

<debug> app: In nrf_bootloader_init

<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...

<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.

<debug> nrf_dfu_settings: Using settings page.

<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Enter nrf_bootloader_fw_activate

<info> app: No firmware to activate.

<debug> app: App is valid

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Running nrf_bootloader_app_start with address: 0x00001000

<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

<debug> app: In nrf_bootloader_init

<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...

<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.

<debug> nrf_dfu_settings: Using settings page.

<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Writing settings...

<debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000

<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 0

<debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 0

<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x20005DE4, len=896 bytes), queue usage: 1

<debug> nrf_dfu_flash: Flash write success: addr=0x0007E000, pending 0

<debug> app: Enter nrf_bootloader_fw_activate

<info> app: No firmware to activate.

<debug> app: App is valid

<debug> app: DFU mode requested via GPREGRET.

<info> nrf_bootloader_wdt: WDT is not enabled

<debug> app: in weak nrf_dfu_init_user

<debug> app: timer_stop (0x200057D8)

<debug> app: timer_activate (0x200057D8)

<info> app: Entering DFU mode.

<debug> app: Initializing transports (found: 1)

<debug> nrf_dfu_ble: Initializing BLE DFU transport

<debug> nrf_dfu_ble: Setting up vector table: 0x00072000

<debug> nrf_dfu_ble: Enabling SoftDevice.

<debug> nrf_dfu_ble: Configuring BLE stack.

<debug> nrf_dfu_ble: Enabling the BLE stack.

<debug> nrf_dfu_ble: Copying peer data

<debug> nrf_dfu_ble: Using default advertising name

<debug> nrf_dfu_ble: Advertising...

<debug> nrf_dfu_ble: BLE DFU transport initialized.

<debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.

<debug> app: Enter main loop

<debug> nrf_dfu_ble: Connected

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE

<debug> nrf_dfu_ble: max_conn_interval: 12

<debug> nrf_dfu_ble: min_conn_interval: 12

<debug> nrf_dfu_ble: slave_latency: 0

<debug> nrf_dfu_ble: conn_sup_timeout: 600

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_SEC_INFO_REQUEST

<debug> nrf_dfu_ble: Sending Service Changed indication

<debug> nrf_dfu_ble: Finished handling conn sec update

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE

<debug> nrf_dfu_ble: max_conn_interval: 6

<debug> nrf_dfu_ble: min_conn_interval: 6

<debug> nrf_dfu_ble: slave_latency: 0

<debug> nrf_dfu_ble: conn_sup_timeout: 500

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_CONN_PARAM_UPDATE

<debug> nrf_dfu_ble: max_conn_interval: 12

<debug> nrf_dfu_ble: min_conn_interval: 12

<debug> nrf_dfu_ble: slave_latency: 0

<debug> nrf_dfu_ble: conn_sup_timeout: 600

<debug> nrf_dfu_ble: Received BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST (request: 517, reply: 247).

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST.

<debug> nrf_dfu_ble: Received BLE_GAP_EVT_DATA_LENGTH_UPDATE (251, max_rx_time 2120).

<debug> app: In nrf_bootloader_init

<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...

<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.

<debug> nrf_dfu_settings: Using settings page.

<debug> nrf_dfu_settings: Copying forbidden parts from backup page.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.

<debug> app: Enter nrf_bootloader_fw_activate

<info> app: No firmware to activate.

<debug> app: App is valid

<debug> nrf_dfu_settings_svci: Erasing settings page additional data.

<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.

<debug> nrf_dfu_settings: Writing settings...

<debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000

<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 0

<debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 0

<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x20005DE4, len=896 bytes), queue usage: 1

<debug> nrf_dfu_flash: Flash write success: addr=0x0007E000, pending 0

<debug> app: Running nrf_bootloader_app_start with address: 0x00001000

<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

RE: Application service UUID gone after secure OTA DFU

SK — Fri, 03 Jan 2020 01:12:13 GMT

Okay, tried doing OTA DFU. Still not working.

Error 0x85 - GATT Error. Before this happens, device resets.

RE: Application service UUID gone after secure OTA DFU

SK — Thu, 02 Jan 2020 08:59:31 GMT

Okay, got it what i was doing wrong there!

will continue to check on the DFU procedure now.

RE: Application service UUID gone after secure OTA DFU

SK — Thu, 02 Jan 2020 08:18:16 GMT

Hi Hung Bui

Sorry, i had to move to some other tasks. I tried to do as you suggested, but i am getting error on the sd_ble_gattc_exchange_mtu_request() --> unknown error code

Would you know why would that be? I have added timer as below.

    if (p_link->att_mtu_desired > p_link->att_mtu_effective)
    {
        NRF_LOG_DEBUG("Requesting to update ATT MTU to %u bytes on connection 0x%x.",
                      p_link->att_mtu_desired, conn_handle);
        create_mtu_request_timer();
        app_timer_start(mtu_request_delay_timer, APP_TIMER_TICKS(1000), NULL);
    }

Rest of the code i have moved in the handler:

static void request_delay_handler(void *p_context)
{
  ret_code_t err_code;
  nrf_ble_gatt_t * p_gatt = (nrf_ble_gatt_t *)p_context;
  ble_evt_t const * p_ble_evt;
  uint16_t  conn_handle = p_ble_evt->evt.common_evt.conn_handle;
  nrf_ble_gatt_link_t * p_link      = &p_gatt->links[conn_handle];
    err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);

    if (err_code == NRF_SUCCESS)
    {
        p_link->att_mtu_exchange_requested = true;
    }
    else if (err_code == NRF_ERROR_BUSY)
    {
        p_link->att_mtu_exchange_pending = true;
        NRF_LOG_DEBUG("sd_ble_gattc_exchange_mtu_request()"
                      " on connection 0x%x returned busy, will retry.", conn_handle);
    }
    else
    {
        NRF_LOG_ERROR("sd_ble_gattc_exchange_mtu_request() returned %s.",
                      nrf_strerror_get(err_code));
    }  
}

Once i connect, i get this error:

<error> nrf_ble_gatt: sd_ble_gattc_exchange_mtu_request() returned Unknown error code.

RE: Application service UUID gone after secure OTA DFU

Hung Bui — Thu, 19 Dec 2019 16:19:44 GMT

The main reason to delay MTU exchange was to wait for the phone to do that. (so that we have larger MTU ATT). I would say give it 1-2 second.

Regarding the issue of having sd_ble_gatts_service_changed() and sd_ble_gattc_exchange_mtu_request() at the same time, you can check if the error is NRF_ERROR_INVALID_STATE the application can retry after a certain time (let's say 1 second) .

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 10:21:08 GMT

Okay sure, will do. In that case, you say putting in a timer to delay the MTU exchange? When should the timer expire? Could you tell me more on the details, please.

RE: Application service UUID gone after secure OTA DFU

Hung Bui — Wed, 18 Dec 2019 10:14:32 GMT

@SK: The issue regarding the MTU request is fixed in SDK v16.0 but not on SDK v15.3 you may want to follow my suggestion in the case.

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 10:05:25 GMT

[quote userid="3284" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226082"]What phone are you testing on?[/quote]

I am testing on samsung S9+ currently.

[quote userid="3284" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226082"]133 is a generic error when "something else" happens, so it may be almost anything[/quote]

That's comforting to know :D

Yes, i will try it out by sniffing the packets and see if i can get somewhere with this error.

[quote userid="69599" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226053"]Would you know anything about this issue? https://devzone.nordicsemi.com/f/nordic-q-a/36346/a-problem-on-buttonless-dfu-bonding-valid[/quote]

This is what Hung said in the link i shared above

"I think we found the root cause of the issue. When you set the MTU to something else not the default that the iPhone set when connected, the nrf_ble_gatt.c will try to request sd_ble_gattc_exchange_mtu_request() immediately right after CONNECTED event."

. Would you know if it is corrected in v15.3? or is it still an issue?

RE: Application service UUID gone after secure OTA DFU

Aleksander Nowakowski — Wed, 18 Dec 2019 09:52:31 GMT

Ideally, the app, after started after successful DFU, should send SC indication, just like the bootloader is sending when switched from app to bootloader mode. On Android you may force clear the cache, like nRF Connect does, but if you want to support iOS as well, there's no such API, not even hidden, so working SC is a must when working with bonded DFU.

The errors 133 happen often, yes. The DFU lib does what it can to try to avoid them, tries many times sometimes, but, a specially on older Android devices and when the device is bonded, the 133 error is common. What phone are you testing on?

If you have sniffer (for example this one: https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE) you may try to find out what's causing this 133 error. Usually it means that there was a packet lost, packet collision, some packets came too early or too late, or, when device is bonded, perhaps something with the encryption. Try putting phone and device close to each other to avoid interference, sometimes disabling wi-fi also helps, as I read in the Internet. 133 is a generic error when "something else" happens, so it may be almost anything.

The 133 around 5 sec after connection attempt seems like the Connect Request was missed by the device and it continued to advertise instead. Retries should increase the chance of success.

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 09:43:51 GMT

and it seems, sometimes i get that 133 error and other times ( which is 2/10) i get DFU done successfully.

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 09:42:46 GMT

[quote userid="3284" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226057"]You need to select "Refresh services" in the top menu to clear the cache and do service discovery again[/quote]

This worked! so we will have to do everytime we try to do OTA DFU, then?

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 09:34:39 GMT

oh alright, in that sense, yes.

BTW, i tried again and this time i got 133 error. Attached. devzone.nordicsemi.com/.../Log-2019_2D00_12_2D00_18-17_5F00_32_5F00_29.txt

One more

devzone.nordicsemi.com/.../Log-2019_2D00_12_2D00_18-17_5F00_37_5F00_21.txt

RE: Application service UUID gone after secure OTA DFU

Aleksander Nowakowski — Wed, 18 Dec 2019 09:31:31 GMT

Doesn't matter, it's still "new", as it was updated. After exiting bootloader it should notify client that services have been have changed.

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 09:29:29 GMT

[quote userid="3284" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226057"]but your new app, when first started,[/quote]

new app and app on the device are the same actually. No change at all. :(

RE: Application service UUID gone after secure OTA DFU

Aleksander Nowakowski — Wed, 18 Dec 2019 09:26:29 GMT

The DFU seems to complete successfully, but your new app, when first started, didn't send the Service Changed indication (or sent it too late), so the services obtained by nRF Connect were from cache. You need to select "Refresh services" in the top menu to clear the cache and do service discovery again. You should see the UART and buttonless service after that.

I don't know why the indication was not sent, that's outside of my expertise.

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 09:16:51 GMT

Would you know anything about this issue? https://devzone.nordicsemi.com/f/nordic-q-a/36346/a-problem-on-buttonless-dfu-bonding-valid

Seems exactly what i am getting here.

I tried with changing NRF_BLE_GATT_BLE_OBSERVER_PRIO from 1 to 2 in both bootloader and application but it doesn't work. And Hung Bui solution i did not understand. 😞

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 09:12:33 GMT

Hi,

[quote userid="3284" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226032"]That means you're connected to the bootloader[/quote]

What should i do to rectify this behavior? This is not observed while performing buttonless DFU without bonds.

[quote userid="3284" url="~/f/nordic-q-a/55705/application-service-uuid-gone-after-secure-ota-dfu/226032"]In the log you got error 133,[/quote]

Now, i am getting gatt write not permit error and not 133. I am not sure why though! devzone.nordicsemi.com/.../1072.Error.txt

RE: Application service UUID gone after secure OTA DFU

Aleksander Nowakowski — Wed, 18 Dec 2019 08:14:47 GMT

That means you're connected to the bootloader. In the log you got error 133, could you try repeating the test several times and send log where it went further?

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 05:54:40 GMT

Hi,

This is what i tried and now it seems problem is with bond forwarding somehow.

I disabled the bond forwarding support in both bootloader and the application. So, basically this below:

When i tried without bonds, everything is working fine. I can see both services intact and running fine.

Only when i tried to enable the bond support again, i ran into problems as discussed earlier.

Attached is the no bonds support DFU log for your reference. devzone.nordicsemi.com/.../DFU_5F00_NO_5F00_BONDS_5F00_LOG_5F00_SUCCESS.pdf

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 01:45:38 GMT

Hi,

I noticed something strange though. Wanted to share here.

Once i program the device through nrfjprog and connect, i see the services as below:

After OTA DFU, when i connect again, i see the service as below:

I noticed that characteristics for the secure DFU service is not buttonless service anymore and its something that is coming from bootloader (control point and packet characteristics).

Would this give any indication to what might be happening? Any DFU settings that i should enable/disable in sdk config?

Attached - dfu logs for reference.

devzone.nordicsemi.com/.../DFU_5F00_LOG_5F00_ISSUE.pdf

RE: Application service UUID gone after secure OTA DFU

SK — Wed, 18 Dec 2019 01:09:59 GMT

Oh yes! it won't start advertising. Only after there is a button press, it will. :/

Do u want me to modify pins for the DK in order for you to test?

RE: Application service UUID gone after secure OTA DFU

Aleksander Nowakowski — Tue, 17 Dec 2019 11:04:56 GMT

Hello, I tried flashing your hex file on nRF52832 DK, but the device does not start advertising.

RE: Application service UUID gone after secure OTA DFU

SK — Tue, 17 Dec 2019 09:12:45 GMT

Sent. I hope pins don't matter. Please let me know if there are problems.

RE: Application service UUID gone after secure OTA DFU

Aleksander Nowakowski — Tue, 17 Dec 2019 09:08:05 GMT

Send to aleksander.nowakowski@nordicsemi.no.

I hope the pin configuration won't matter.