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

dfu fails only if bonded

Hello,

Thanks for reading this! I have an odd behavior on my nrf52832 where I am capable of uploading a new firmware via BLE DFU to the peripheral device if it is not bonded to the central device. However, when I bond, the DFU always fails. I suspect it is for this reason, ie the NOINIT section in the ram is not retaining my bond information when passing to the bootloader. I am using Elcipse GCC, so in order to rectify this, I have to modify this linker script: dfu_gcc_nrf52.ld. I dont know how to do so, can anyone point me in the right direction? Is there any way to check that there is indeed bond information retention?

Thank you very much for your time.

edit for phone screenshot: image description

Parents
  • Hi Sean,

    I tried with the latest SDK v11 production (released yesterday) and compile with gcc and tested here, it worked fine with and without bonding. I attached here the hex file of the bootloader and the .zip file for updating, could you test on your side ?

    Note that you need to use the S132 v2.0.0 production. To trigger bonding you can try to write to CCCD of the heart rate service

    myapp.zip

    bootloader_s132.hex

    Update 15 Mar:

    For SDK 0.9.2

    bootloader.hex

    myapp.zip

    pstorage_platform.h

    dfu_app_handler.c

  • The bootloader from sdk11 works fine on its own as long as I use the newer version of the softdevice. However, my application is based on the sdk 9.2 so I cannot use the newer softdevice. I believe the newer SD uses a different device manager, the peer manager, and I assume it has numerous other differences, not to mention that I have heavily modified the bootloader in order to support functionalities I need, so I would prefer not to have to migrate to sdk11. Note, however, that the bonding issue is present when I use an unmodified version of the bootloader. This would indicate that either 1. the bootloader as it is given in the sdk9.2 is incapable of exchanging peer information or 2. my application has a fault in it. Would you be able to test on your end if the bootloader from 9.2 is capable of peer information exchange when bonded? That would isolate one variable and I can then confirm that the issue is not memory mapping from the linker file or an inherent flaw of the bootloader from 9.2, but rather an issue with my application. Thanks!

Reply
  • The bootloader from sdk11 works fine on its own as long as I use the newer version of the softdevice. However, my application is based on the sdk 9.2 so I cannot use the newer softdevice. I believe the newer SD uses a different device manager, the peer manager, and I assume it has numerous other differences, not to mention that I have heavily modified the bootloader in order to support functionalities I need, so I would prefer not to have to migrate to sdk11. Note, however, that the bonding issue is present when I use an unmodified version of the bootloader. This would indicate that either 1. the bootloader as it is given in the sdk9.2 is incapable of exchanging peer information or 2. my application has a fault in it. Would you be able to test on your end if the bootloader from 9.2 is capable of peer information exchange when bonded? That would isolate one variable and I can then confirm that the issue is not memory mapping from the linker file or an inherent flaw of the bootloader from 9.2, but rather an issue with my application. Thanks!

Children
No Data
Related