Hi,
We have some custom boards with NRF51822 and the S110 (v8.0.0) softdevice, on which we have programmed the dfu dual bank bootloader, based on the example one from the SDK. The bootloader is at its default start address (0x3C000) and it seems to work ok. It can update the application firmware and it can update itself; I've created a zipped hex image for the same bootloader using the "nrfutil.exe dfu genpkg --bootloader" command and sent it OTA to the device, and that worked ok.
However, this bootloader does not preserve application data, and we need to preserve those in order to not lose bond information across dfu updates (our application firmware uses the buttonless dfu)
So, as per the documentation I have edited the dfu_types.h to allocate 3 pages using DFU_APP_DATA_RESERVED -- the goal being to preserve 2 (two) pages for pstorage in addition to the one (1) that is for swap. infocenter.nordicsemi.com/index.jsp
I'm using Keil Studio to compile the code, and I kept the mem Target settings of the original bootloader, that is: mem start at 0x3C000 and size: 0x3C00
If I send the corresponding zip image of this bootloader (eg bootloaderAppSave.zip) to the board (that has the previous bootloader) then after the dfu update the device is no longer discoverable and appears to not be working anymore.
If I use a programmer and nRF go Studio to flash the softdevice and then the new bootloader, then the bootloader works ok. It can also update itself if I send the new zip image (the bootloaderAppSave.zip) to it.
I tried dumping the flash data using the "nrfjprog -f nrf51 --readcode" to see if I notice anything strange. I compared this dump with the flash dump from a working version of the new bootloader (when using a programmer to flash it)
When the new bootloader is sent OTA to the device running the old (non app data preserving) bootloader then:
-
At address 0x00000800 it has some data (0x0000000000980200AC0C000000000000), whereas normally (old bootloader and new bootloader flashed with programmer) the bytes there are all 0xFF (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
-
The full bootloader image is copied (as expected) in an intermediate flash location (from 0x0002A000 to 0x0002D2A0) (actual size: 0x32A0).
-
At address 0x0003C000 is unwritten up to 0x0003C7FF), and the bootloader image starts at 0x0003C800 and goes up to 0x0003F2A0 at which point it is truncated. So the bootloader does not start at the expected address (0x3C000 as per the UICR that I read with nrfjprog) and only 0x2AA0 bytes of the 0x32A0 are copied there, shifted by 0x800.
Any ideas why this is happening?
I need to be able to update the OLD bootloader firmware over-the-air; flashing all of our devices with a programmer is not an option.
