Bootloader-Only update over BLE DFU

RE: Bootloader-Only update over BLE DFU

Edvin — Tue, 21 Aug 2018 11:58:56 GMT

Hello,

I am not quite sure about this one. I thought the bootloader would delete the application if it was not space for dual banking.

What SDK is your original bootloader based on?

Is it possible to reproduce this on an nRF52DK? Is it possible to send the original bootloader project, and also the application that is on the chip? At least the .hex file, so that I can try to reproduce it?

I also found another case with someone else facing the same issue. Do you use the debug bootloader project? Do you have dual banking enabled (in sdk_config.h on the bootloader project)?

Best regards,

Edvin

RE: Bootloader-Only update over BLE DFU

jmag999 — Mon, 20 Aug 2018 14:50:57 GMT

Also, how does the bootloader determine the space that is has to work with?

RE: Bootloader-Only update over BLE DFU

jmag999 — Mon, 20 Aug 2018 13:56:54 GMT

I am using a nRF52832 with 512KB flash. My application is 186K and I am using the S132 V5.0 softdevice. There should be plenty of space leftover. Are there any other requirements on this space?

RE: Bootloader-Only update over BLE DFU

Edvin — Mon, 20 Aug 2018 13:50:43 GMT

Hello,

When you are updating using j-link, you are reprogramming the device using the programming chip. When you use the bootloader to update any firmware, the chip must do this itself. Therefore, it will not delete the old bootloader before the new one is verified. Hence, you need to have space for 2x bootloader for the chip to accept it. The reason for this is that the bootloader is needed to transfer the packet.

Are you sure there is enough room in the ram/flash to store the new bootloader?

Best regards,

Edvin