dfu fails only if bonded

[seanbites]

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:

[Hung Bui]

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

[seanbites]

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!

[Hung Bui]

Hi Sean,

Just to clarify we don't have SDK v9.2 it's nRF52 SDK v0.9.2.

This SDK is alpha and is not production grade, especially the S132 v1.0.0-3alpha. You could have an issue if you want to qualify your product with S132 v1.0 alpha.

So I strongly suggest you to move to the production version S132 v2.0.

Note that the SDK v11 still use device manager. You should not have too much problem porting to the new softdevice and the SDK.

However, I also did some investigation on the issue with bonding and DFU on SDK v0.9.2. Yes, there are some modification needed:

• Please copy and replace function pstorage_flash_page_end() in your pstorage_platform.h the one in the same file in SDKv11\examples\ble_peripheral\ble_app_hrs\config. This will solve the issue that storing bond information will overwrite the bootloader.
• Replace the nRF_UICR->BOOTLOADER_ADDRESS with NRF_UICR->NRFFW[0] in dfu_app_handler.c

I attached in the answer the updated files.

P/S: Sorry I was confused between 2 version, yes in SDK v11 production in some examples we switched to peer manager, but there are still some examples use device manager such as ble_app_hts

[seanbites]

Yes, this is what I feared. I will port my code to the SDK11 this weekend. Thanks a lot for your help!