Loading Image in app and passing to bootloader

[Malcolm]

I am using SDK16 and attempting to load images for loading.I have questions and would welcome pointers

1. I need to use the application to load a new image into memory ready for loading. What is preferred method to pass information to the bootloader so that it will load the image on next reboot? I have adapted open bootloader to remove all the transports.

2. When I am developing an application and use an IDE to load a new image, how can the bootloader be informed there is a valid app so that it runs the app?

[Malcolm]

I accept your point about the bootloader and so I am returning to determine if I can fix issues so the bootlloader will cooperate with my app:

1. How do I initialise access to memory used by the bootloader within my app to pass information on the image to flash (i.e write to bank 1 with parameters)?

2. How do I ensure my app creates a separate area in flash for FDS storage so it does not use the same area as bootloader?

3. When the bootloader starts an app (nrf_bootloader_app_start) how do I initialise NRF_LOG to use RTT. Before the bootlloader was used this used to work, but now I only see bootloader messages?

[Edvin]

1: Not sure exactly what you mean? Do you mean how to tell the bootloader to start the DFU process, moving the new application to the correct place? If so, you can look at the ble_app_buttonless_dfu example, which does this. It writes a value to the GPREGRET register in ble_dfu.c:

    err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
    VERIFY_SUCCESS(err_code);

This register is retained during resets, and the bootloader checks this register on startup to decide whether to enter DFU mode or not.

Malcolm said:

2. How do I ensure my app creates a separate area in flash for FDS storage so it does not use the same area as bootloader?

In your bootloader's sdk_config.h, you will find a definition:

NRF_DFU_APP_DATA_AREA_SIZE

Which is the number of bytes closest to the bootloader (the top, right beneath the bootloader) that the bootloader will never touch. This is the location where FDS is also being placed. By default, this has the value 12288, which is 3 flash pages, but you can adjust this to fit your application.

Malcolm said:

3. When the bootloader starts an app (nrf_bootloader_app_start) how do I initialise NRF_LOG to use RTT. Before the bootlloader was used this used to work, but now I only see bootloader messages?

The way that RTT logging works is that the messages are written to an area in ram. When you have two instances (bootloader and application) using RTT, then these will end up in different places. Unfortunately, the way that the RTT terminals work is that it looks for a special word in RAM where it will find the logs. It usually looks until it finds it, and starts printing the logs from there. So if you have two places in RAM where this appears, then you need to either search for another address where this is set. You can specify what addresses to search in, so if you find the first place in one RTT log instance, you can search for only the ram addresses after that.

Or a simpler option is probably to disable the RTT logging from the bootloader when you want to monitor the logs from the application.

Best regards,

Edvin

[Malcolm]

1. I have used GPREGRET in the application to signal to the bootloader to commence loading a new image.

2. I am struggling to understand how to configure FDS so that my application and the bootloader can share a common area of memory.  I can get them to use separate areas. However I need to exchange information on the location and size of the image to load. The bootloader uses FDS to define an area to store information on the banks, and my application uses FDS to define an area to store information on the image to load. Somehow one needs to access the information of the other.

3. The simple option works fine.

[Edvin]

Oh, I think I misunderstood you in your previous reply, regarding the shared memory.

Usually the way this works, is that this is part of the init packet (and then later the bootloader settings, which holds information about the application image. 

I am actually not sure what the best way to do this without an init packet, which I guess that you don't have. I guess I would look into just using the first flash page in the bank to store the size of the application (or elsewhere), and this information will be present when the bootloader is told to start changing the application. Use the first page to store your application information (size, CRC, and so on), and then you store the actual application image from the second page and onwards.

Best regards,

Edvin

[Edvin]

It may sounds a bit too much to use an entire flash page for this, but I imagine it is easier to have this at a known address, and also that it is better to copy N pages from page 2 (the application image) into where it is supposed to be, rather than having this awkward offset. An alternative is to store it somewhere else that is known, but that will be the page right beneath the FDS pages (since you can only erase an entire flash page at the time, it is probably easier to use an entire flash page for this). Another option is to store it in FDS, but that would require you to add FDS to your bootloader as well, which will increase the size of your bootloader. (Or you can look into the structure of FDS, and implement a parser looking for the record containing the start address and size of the new image. Sort of like a strip down version of FDS).

Best regards,

Edvin