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?

[Edvin]

Hello,

I have adapted open bootloader to remove all the transports.

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

[Malcolm]

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.

[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

[Malcolm]

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..

[Edvin]

Malcolm said:

There could be several approaches such as a link (SWI?)

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

[Malcolm]

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,

[Malcolm]

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.

[Edvin]

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