This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

dfu of nrf connect IOS doesn t work

Hello,

we are developing a machine that is in pre-production. We need to be able to update the firmware and until now all works well on android. but on IOS the dfu does not work.

I use the same device with the same firmware to update. it's ok on android nRF Connect for Mobile version 4.22.3

but does not work on IOS nRF Connect Version 2.0.2

it seems to me that it worked on IOS with version 1.8.8

I use:

nrf52832, SDK version: 15.3.0, Soft Device version: S132 V6.1.1

the device does not start in dfu target mode.. 

is there a problem with the IOS application? do I have to change something in my firmware to be compatible with the new version? 

thanks for the quick help ... we must soon produce our device.

Parents
  • Hi Sarah, 

    Could you capture a sniffer trace when you start doing DFU 

    I assume you are doing DFU buttonless ? 

    Do you support changing advertising name in your DFU buttonless application ? Do you have any modification in the buttonless library and the bootloader ? 

    If you test with the stock DFU buttonless example in our SDK would it work ? 

    Could you try to manually enable notification on the DFU buttonless characteristic and write 0104 into it? It should switch to DFU target. 

Reply
  • Hi Sarah, 

    Could you capture a sniffer trace when you start doing DFU 

    I assume you are doing DFU buttonless ? 

    Do you support changing advertising name in your DFU buttonless application ? Do you have any modification in the buttonless library and the bootloader ? 

    If you test with the stock DFU buttonless example in our SDK would it work ? 

    Could you try to manually enable notification on the DFU buttonless characteristic and write 0104 into it? It should switch to DFU target. 

Children
  • Yes I use DFU buttonless,

    When I manually enable notification on DFU buttonless characteristic and write 0104 the device reset the bootloader with name "DfuTarg" and I can connect to the device and update the firmware without any problem. and after the device restart the application.

    But when I connect to my device and I go on the page DFU, I can select the firmware to update (step3), go in step4 ready to update, but when I click on start I remain stuck on step 5 uploading and the device does not restart in bootloader "DfuTarg".

  • I don't make any changes to the dfu library and bootloader, but how do I check if the changing advertising name is supported?
  • Do you use bonded or unbonded buttonless (ble_dfu_bonded.c or ble_dfu_unbonded.c) ? 

    The handling of changing the advertising address is inside ble_dfu_buttonless_on_ctrl_pt_write() on DFU_OP_SET_ADV_NAME event. 

    The reason we do this is to help the mobile app to recognize the device when it start advertising as in bootloader mode (DfuTarg name, by default). 

    In the new app (v2.0.2) we don't have an option to turn this off but we are releasing new version that should come in a few days. 

    If you can capture a sniffer trace of the DFU process we can have a clearer view of where the issue is. 

    Are you planing to have your end customers to use nRF Connect app ?

    If you are writing your own mobile app to do DFU this should be fixed easily as you can see if you do it manually by writing 0x0104 it would work fine. 

  • actually I use unbonded buttonless. 

    but for the next step, I will have to allow the dfu only if the device and paired how to do it?

    We will use our own application, so I think we will not have this problem because the dfu works in a manual way.

    you will find the sniffer trace that I could do on android and IOS, with the same device and the same firmware.

    ios.pcapngandroid.csvandroid.pcapngios.csv

  • Hi Sarah, 

    From the ios.pcapng I can see clearly the device crashed after the advertising name change request (packet 519). If you want you can try to add a breakpoint inside the handle of ble_dfu_buttonless_on_ctrl_pt_write() to check why it crashes (and reset). 

    The reason we added the device name change request is that when you have multiple device which can advertise as DFUTarg, you may not be able to detect which one you should connect to and do DFU. So we give the unique name instead. So it depend on your use case, if the chance of having multiple device all switch to DFU mode at the same time is small, I think it's fine to not changing the name. 

Related