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

  • 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

Reply
  • 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

Children
No Data
Related