Bootloader and Settings not recognized once application starts. Possible memory allocation issue?

[Arif@Lynxemi]

I have a known working distribution (ZIP) file that when flashed onto a device, correctly goes into the application and is able to do buttonless DFU. This was left behind by a previous engineer.

I modified the bootloader to show debug statements to RTT and to change the UUID when in DFU mode (from the default DfuTarg). I then generated a settings hex file and the distribution ZIP using nrfutil as such:

nrfutil settings generate --family NRF52840 \
        --key-file $KEYFILE \
        --application $HEXFILE --application-version 0 \
        --bootloader-version 0 --bl-settings-version 1 \
        $SETTINGSFILE

nrfutil pkg generate --key-file $KEYFILE --application $HEXFILE $PKGFILE \
        --hw-version 52 --sd-req 0xAE --application-version 0 \
        --bootloader $BL_FILE  --bootloader-version 0 \

When I program up a DK with the combined hex files, it goes into application mode as supposed but it fails to recognize the bootloader and settings Thus I can't go into buttonless DFU. nrfConnect Programmer shows this:

The merged hex files are on the right and it shows that the bootloader and settings are viewed as application data on the DK. For comparison here's the working ZIP:

It has recognized the bootloader and settings.

nrfConnect Programmer shows that the bootloader, settings and softdevice are set to the same address in memory however, the size of the bootloader and application is different obviously due to the changes I've made. I've tried reverting my changes to the bootloader but no luck.

I'm using a nRF52840-Preview-DK and SDK15.2.0.0.

Can anyone tell me what's wrong?

[Edvin]

Hello,

First of all, the color coding in nRF Connect for Desktop doesn't matter in this case. It is just an educated guess, and based on how the flashed .hex file looks. Whether it is green, or it has the black and red sections doesn't say anything about the content. 

So the short answer is that I don't know whats going on without knowing anything about the changes you have done to the bootloader. If you have flashed a softdevice and a bootloader, then the bootloader will always execute before the application. You say that the issue is that you can't go back to DFU mode? If so, I would suggest that you try to start with an unmodified bootloader just to see how things work. You can follow this guide. 

Then, if you want to know why the bootloader doesn't go into DFU mode, I suggest you check the ..._debug bootloader project, and look at the RTT log output. It should give some hints.

BR,

Edvin

[Arif@Lynxemi]

Hi Edvin,

You're right that the color coding is not a good indication of the problem. I am getting debug errors from RTT about no bootloader being recognized though.

I tried your suggestion with an unmodified bootloader and it works. However, I think I found the root of the problem to not be the bootloader, rather the implementation of the application. I discovered that in order to set a specific variable in non-volatile memory, the process was to erase a page and then write a word. I have no idea why this was done but I corrected it and now I have it working. Problem code:

		nrf_nvmc_page_erase(NET_ID_Address);
		nrf_nvmc_write_word(NET_ID_Address, NET_ID);

I suspect the nvmc_page_erase was erasing into the bootloader section. My bootloader had roughly doubled in size with my modifications and it probably fell into the page.

R,

Arif