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

SDK12 DFU service not found

I am developing software for a custom hardware based on NRF52. Previously I was tasked on updating the old NRF51 based software (used on older version of the device) for NRF52 using SDK11. Once that was done my next task was updating the software for SDK12. The software is otherwise working fine but I am having problems with DFU. I tried creating a zip of the application and flashed the combined softdevice/bootloader from SDK12 examples folder (dfu/ble_dfu_send_hex) to the device. The device shows as DfuTest on the mobile DFU app but when I try to upload the zip all I get is "DFU service not found". I also tried compiling the secure DFU bootloader example and using that instead but the result is the same.

Do I need to also have DFU support in the application for that to work ? Currently the application has some kind of DFU functionality from the earlier SDK 11 implementation but I'm guessing that wont work. Any examples to study so that I can implement the functionality ?

  • I am using unmodified bootloader. Anyway, there is now significant progress after I modified the linker settings and rebuilt. Now the system works pretty well:

    1. Erase the flash and flash softdevice and bootloader. Device is shown as DfuTarg in NRF Connect as expected.
    2. Upload the application using DFU. The application starts and appears to work fine. Device is shown as "BTL4X1 2.49" as expected.
    3. Force transfer to bootloader by setting the characteristic to 0x1. Device is once again shown as DfuTarg.
    4. Reset the device by unplugging the power/log lead.
    5. Upload the application using DFU.

    Part 4 is the only problem right now. Even though the device is shown as DfuTarg as it should it appears it is not properly reset and DFU doesn't work (it just gets stuck showing "Uploading"). But if I force a reset I can DFU just fine.

  • Update: I added setting of flag is_waiting_for_disconnection to reception of message "enter bootloader". Now the software is working fine and even the restart on setting the bootloader switch characteristic works.

    Though the method of forcing the user to set the characteristic to force switching to bootloader would not be very user friendly for customer project...

  • Hi Jpolvi,

    I'm glad that it's smooth now. I will check why if we don't wait for the disconnection we may run into problem. I don't really get this part "Though the method of forcing the user to set the characteristic to force switching to bootloader would not be very user friendly for customer project...". What would be your preferred way of switching to bootloader ?

  • I guess that is the best way to be able to use the application as needed and update when necessary. It's just that "unknown characteristic" and "unknown property" are not very descriptive if one does not know what should be done.

  • You mean to integrate bootloader into application ?

    The "unknown characteristic" happens because it was experimental project (we created just for SDK v12v1) and we re going to replace that characteristic with another one when we move the example to official.

    Note that you can always modify your app to recognize the "unknown characteristic" as DFU characteristic to make the end user experience better.

Related