Loading Image in app and passing to bootloader

RE: Loading Image in app and passing to bootloader

Edvin — Mon, 28 Oct 2024 08:45:00 GMT

Seems like you know what you are talking about!

Remember that the bootloader needs two pages above itself. The MBR params page and the bootloader settings page. So make sure you have room for these.

Best regards,

Edvin

RE: Loading Image in app and passing to bootloader

Malcolm — Fri, 25 Oct 2024 15:23:30 GMT

An update. I removed all references to unused code that included security code and my image is down to 16k (uncompressed) so I moved up. I had to fiddle with the bootloader code to prevent my common memory becoming protected (between bootloader and MBR parameters) and not erase the FDS area under bootloader. So I have a split bootloader/app functioning. Thank you for hints.

RE: Loading Image in app and passing to bootloader

Malcolm — Thu, 24 Oct 2024 08:08:03 GMT

Thank you for your valuable suggestions. By removing all the transports, and thus security code, and dealing with commands, the bootloader is reduced to 30k (none optimized) and can be moved up to F0000, just below MBR parameters, with 1 page beneath MBR for my parameter passing. I think I have a solution,

RE: Loading Image in app and passing to bootloader

Edvin — Tue, 22 Oct 2024 12:34:28 GMT

[quote user="Malcolm"]There could be several approaches such as a link (SWI?)[/quote]

That is possible, and I know this is being used by the application to tell the bootloader what advertising name to use, but unfortunately I am not very familiar with the very details on how that works. I also don't see why that would be better than just storing it in flash, since this is what the bootloader would have to do after being triggered by SWI either way, so that the bootloader can check it after the next reboot.

As I mentioned, the reason you need a separate flash page, and that you can't use the last few bytes of e.g. the bootloader's pages, is that whenever you need to update the values that you write, you need to erase it first, and the smallest partition that you can erase is one flash page (4096 bytes). So if that was the tail of the bootloader, you would need to erase part of your bootloader, which is unfortunate.

Typically the bootloader is pushed as far up (high address) as possible, while reserving a page for bootloader settings and MBR params. So if you have taken away so much of the bootloader that it's flash size has reduced by more than one flash page, I would rather suggest moving the bootloader up one page. Note that it is not possible to move the start address of the bootloader through DFU, so if you want to add features to the bootloader, causing it to increase in size, then you may want to consider leaving an empty flash page above the bootloader.

Either way, I would suggest having this flash page directly beneath your FDS pages, and remember to increase the NRF_DFU_APP_DATA_AREA_SIZE by one page, so that the bootloader doesn't overwrite it during DFU.

Best regards,

Edvin

RE: Loading Image in app and passing to bootloader

Malcolm — Mon, 21 Oct 2024 16:09:37 GMT

Thank you for the suggestions. There could be several approaches such as a link (SWI?) between app and bootloader and include an action block in the call to pass parameters, much as the init.

However there is lots of space between the bootloader (E0000) and MBR parameters (FE000) to use 1 page as common memory available to both and to use simple erase and write functions..

RE: Loading Image in app and passing to bootloader

Edvin — Mon, 21 Oct 2024 13:12:51 GMT

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

RE: Loading Image in app and passing to bootloader

Edvin — Mon, 21 Oct 2024 13:09:32 GMT

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

RE: Loading Image in app and passing to bootloader

Malcolm — Mon, 21 Oct 2024 12:33:00 GMT

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.

RE: Loading Image in app and passing to bootloader

Edvin — Fri, 18 Oct 2024 21:11:23 GMT

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.

[quote user="Malcolm"]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?[/quote]

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.

[quote user="Malcolm"]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?[/quote]

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

RE: Loading Image in app and passing to bootloader

Malcolm — Fri, 18 Oct 2024 10:10:48 GMT

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?

RE: Loading Image in app and passing to bootloader

Edvin — Wed, 16 Oct 2024 09:14:03 GMT

[quote user="Malcolm"]This is easily done by running the required code from RAM so that it is not erased. This works.[/quote]

You should consider what would happen if you loose power during this operation. At least if this is an end product, it is not unlikely that someone are to power off the device, not knowing the consequences.

[quote user="Malcolm"]The hex file contains a value to be written at 10001018 (UICR_PARAM_PAGE_ADDR) and the start address for the application[/quote]

You can't update the UICR on the nRF52840 during runtime. That is, you can write to it if it is 0xFFFFFFFF, but if it is not 0xFFFFFFFF, you can't write to it without erasing it, and you can't erase it from the application on the nRF52840. So if you need to update this register on every DFU, then you can't do that.

But why do you need to update the value at UICR_PARAM_PAGE_ADDR? Wouldn't it be the same every time?

Best regards,

Edvin

RE: Loading Image in app and passing to bootloader

Malcolm — Tue, 15 Oct 2024 16:39:55 GMT

My application already does 90% of the work and so I have decided to add code to erase the old image and flash the new image. This is easily done by running the required code from RAM so that it is not erased. This works.

The hex file contains a value to be written at 10001018 (UICR_PARAM_PAGE_ADDR) and the start address for the application. My question is where to write the start address so that soft device jumps to the correct location to run the application as I do not have a bootloader.

This approach works if I flash the same image as the start address does not change, but will fail if i change the code in the image.

RE: Loading Image in app and passing to bootloader

Edvin — Wed, 09 Oct 2024 10:27:38 GMT

[quote user="Malcolm"]the bootloader does not find a valid image in bank 0 or bank 1 and so sits in the bootloader.[/quote]

This is because it is lacking something called the "bootloader settings", which is a chunk in flash containing some information about the bootloader. When you perform a DFU operation, these settings are generated by the bootloader and stored in the settings page. If you flash the application manually, you need to generate these bootloader settings, and flash it together with the application (for simplicity, I recommend flashing using nrfjprog while dealing with bootloaders. Write a .bat file with the commands you want to run, and run it from your command prompt.)

So after you build your application, you can run something like this:

nrfutil settings generate ... settings.hex
nrfjprog --program <path to application hex file> --verify --sectorerase
nrfjprog --program <path to settings.hex> --verify --sectorerase
nrfjprog --program <path to bootloader.hex> --verify --sectorerase
nrfjprog --reset

you can copy this text into a file called e.g. test_application_and_bootloader.bat, and run it from a cmd line.

[quote user="Malcolm"]The hex (srec) file contains the separate address sections where to load. How is the bootloader expected to deal with loading these separate sections?[/quote]

Does your application.hex actually program these addresses, or are they indirectly written by the application?

I guess that it is not part of your application hex file, but the application writes to a certain area in the upper flash during runtime, which would also be the case if you are using e.g. the peer manager to store bonding data for Bluetooth connections.

In that case, the bootloader will set aside an area in the top of the flash, right before the bootloader itself. The size of this area is determined by a define in the bootloader's sdk_config.h called NRF_DFU_APP_DATA_AREA_SIZE. This is the size (in bytes) that the bootloader will never touch, either for validating the application, or while performing a DFU. By default this is set to 3 flash pages (each flash page is of size 4096 bytes).

If you are using FDS in addition to some custom data on different flash pages, make sure that they are all in the top of the flash (the FDS pages will automatically be closest to the bootloader), and that the NRF_DFU_APP_DATA_AREA_SIZE is up to date.

Best regards,

Edvin

RE: Loading Image in app and passing to bootloader

Malcolm — Wed, 09 Oct 2024 07:52:20 GMT

I have a further question. My image contains several separate code sections, normally this is the app and then a section to write to the various registers in upper memory. The hex (srec) file contains the separate address sections where to load. How is the bootloader expected to deal with loading these separate sections?

RE: Loading Image in app and passing to bootloader

Malcolm — Tue, 08 Oct 2024 14:54:56 GMT

I need to clarify my question. When I am developing code I develop in the IDE and then use the IDE to load directly to flash - I do not use the DFU to load the new image. In this case the bootloader does not find a valid image in bank 0 or bank 1 and so sits in the bootloader.

I can change the code so that I poke 1 into bank 0 to fool the bootloader and so run the new image, but I wondered if there was a preferred method using a flag.

RE: Loading Image in app and passing to bootloader

Edvin — Tue, 08 Oct 2024 13:53:37 GMT

What I tried to say was that you use the GPREGRET to tell the bootloader to do DFU stuff instead of just starting the old application (which is the default behavior). When you do so, the bootloader will start investigating the image present in bank1. If it is valid, it will perform a swap, so that whatever was in bank1 will be moved to bank0, and then it will start the new app which then will be present in bank0.

BR,
Edvin

RE: Loading Image in app and passing to bootloader

Malcolm — Tue, 08 Oct 2024 08:21:27 GMT

Thank you for the hints. I think I understand how I can use common MBR memory to pass the paramaters to flash the image that is loaded and use GPREGRET to indicate to the bootloader to start the process.

My remaining question was how an app loaded using IDE can indicate to the bootlloader there is a valid app and so the bootloader runs the app. I am assuming it has to write to bank0?

RE: Loading Image in app and passing to bootloader

Edvin — Mon, 07 Oct 2024 13:10:16 GMT

I see. This example bootloader is intended for the nRF52840 Dongle, which has a USB bootloader where the security is taken out, because it should work with the nRF52840 dongle, which doesn't have a bootloader. Hence, the default way to update the application running on it is via nRF Connect for Desktop -> Programmer. Hence it should accept .hex files that are not signed, but part of the magic here happens in nRF Connect for Desktop, which is not open source. Hence, I recommend that you start with the secure_bootloader example.

So the way this normally works, is to use the ble_app_buttonless_dfu example, and implement this into your custom application. In this example the application only tells the bootloader that it will receive a new image, and that the bootloader should restart in DFU mode. So your task will be to make the application handle the transfer part, and when this is done, and the new image is stored in flash, tell the bootloader to start working on it. You must decide whether you want to implement the "init packet" which contains the signature of the application and the size of it, which is usually used to check that 1: The image is valid, signed with the proper key, and 2: whether it will fit in a second slot or not. In your case, it needs to fit in a second slot, because it is the running application that handles the transfer.

To tell the bootloader to enter DFU mode, it uses the GPREGRET register, which is retained during the reset, and checked in the bootloader's:

nrf_bootloader_init() -> dfu_enter_check() which checks the GPREGRET register.

You can also see in the nrf_bootloader_init() that it checks bank 1 whether a new application is present. So if everything is in transferred and stored correctly, then you may be able to just reset, and check if the bootloader picks it up.

Some other useful functions: on_data_obj_execute_request_sched() and on_data_obj_execute_request() in nrf_dfu_req_handler.c, which are the functions triggered when either the init packet or the entire image is transferred, and the bootloader should take action.

Best regards,

Edvin

RE: Loading Image in app and passing to bootloader

Malcolm — Fri, 04 Oct 2024 14:27:32 GMT

I started from an example in SDK16 called open_bootloader and disabled all the transports as these are not used in the bootleader, rather the applications places a binary copy of the image in flash using a file sent in ascii format, either hex or srec, and coverts on the fly. This provides information on load address, store address, and size, and could also manage merged hex.

My questions are:

1. How does my application pass information to the bootloader that there is an image in flash to be loaded. Is there a preferred method. If not then I can use a common area of flash.

2. If I have a bootloader, how do I provide information to the bootloader that there is a valid application to run if I load the application using the flash tools provided by an IDE.The problem is that I can't use the app to signal the bootloader as the app is never run.

RE: Loading Image in app and passing to bootloader

Edvin — Fri, 04 Oct 2024 13:24:52 GMT

Hello,

[quote user=""] I have adapted open bootloader to remove all the transports.[/quote]

What bootloader, exactly did you start with?

IT's been a while since I looked into this, but there are ways to make the bootloader use images already stored in flash. You need to store it in flash as if it was uploaded by the bootloader itself, but I am not sure about what you mean by "Open bootloader" Did you disable the security? Or just the transport layers?

Best regards,

Edvin