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

Softdevice/Bootloader update from S2.0.1 to 3.0.0 does not boot

I am trying to update my S132v2.0.1 devices over the air to S132v3.0.0 and am getting no bootup, even after swapping dfu_dual_bank.c from the answer below.

devzone.nordicsemi.com/.../

Although the SD seems to update, NRFUtil shows the bootloader size is 24kb instead of the new size of 32kb, and the start address is unchanged after the update is complete. The logs from the mobile device indicate a successful update.

I need to update devices over the air and cannot re flash them.

I am also unsure where to install dfu_dual_bank.c in the new bootloader, as the SDK12 secure bootloader does not have this file.

I have not modified any of the relevant files, I am building ble dual bank S132 bootloader in SDK11 with the batch, and using the new secure bootloader built from SDK v12.1.0. I am then packaging this bootloader using the old NRFUtil from SDK11 with arguments :

nrfutil dfu genpkg --bootloader nrf52832_xxaa_s132.hex --application-version 0xffffffff --dev-type 0xffff --dev-revision 0xffff --sd-req 0xfffe 'patchedBL.zip'

When building the new bootloader with IAR or KEIL, the FW update fails to initiate with this in the mobile log.

[DFU] Remote DFU error: REMOTE DFU DATA SIZE EXCEEDS LIMIT
Parents
  • I believe that the case you're referring to is regarding the update from a Legacy bootloader + S132 v2.0.x to a legacy bootloader + S132 v3.0.0, where you have to implement a bugfix in order to successfully perform a DFU. The bugfix is explained in this post

    devzone.nordicsemi.com/.../

    In order to update from the bootloader in SDK v11.0.0 (now referred to as Legacy) to the bootloader in SDK v12.x.0 ( referred to as Secure) you have to ensure that the start address of the legacy bootloader that is flashed to your devices is identical to that of the new Secure Bootloader as this cannot be changed at runtime without erasing the entire chip.

    The default start address of the legacy bootloader is 0x0007A000, while the default start address of the Secure bootloader is 0x78000, i.e. the legacy bootloader start address must be set to 0x78000 so that there is room for the new Secure bootloader.

    Like the legacy to legacy update, you have to add a bugfix to the Legacy bootloader, as explained in the post linked to above.

    Best regards

    Bjørn

Reply
  • I believe that the case you're referring to is regarding the update from a Legacy bootloader + S132 v2.0.x to a legacy bootloader + S132 v3.0.0, where you have to implement a bugfix in order to successfully perform a DFU. The bugfix is explained in this post

    devzone.nordicsemi.com/.../

    In order to update from the bootloader in SDK v11.0.0 (now referred to as Legacy) to the bootloader in SDK v12.x.0 ( referred to as Secure) you have to ensure that the start address of the legacy bootloader that is flashed to your devices is identical to that of the new Secure Bootloader as this cannot be changed at runtime without erasing the entire chip.

    The default start address of the legacy bootloader is 0x0007A000, while the default start address of the Secure bootloader is 0x78000, i.e. the legacy bootloader start address must be set to 0x78000 so that there is room for the new Secure bootloader.

    Like the legacy to legacy update, you have to add a bugfix to the Legacy bootloader, as explained in the post linked to above.

    Best regards

    Bjørn

Children
No Data
Related