Communicating between Application and Bootloader

[Annakin4]

Hey All,

Noobish question, but I want to make sure I do this the right way and not in a "it just works" way. I wrote a bootloader for updating my device, and I want to be able to reset the micro from the application and start the update process, but only when the application requests it, the reasoning being I do not want to add all the code to the function that jumps to the application or determines to stay in bootloader mode to check the SPI flash for a new bootloader version.

The bootloader is based off the Microsoft UF2 bootloader, and it already contains a method for persisting a "Magic" value in RAM across a reset (But never when there is an application), this location is a 32 bit value at the top of RAM (HSRAM_ADDR + HSRAM_SIZE-4). When there is a specific value at that memory location, the bootloader stays in the bootloader, and if not, it starts the application. I just did a dirty additions of another magic that would put it in a firmware update mode not really expecting it to work, shocker, it didnt. If I run the line `*MAGIC_LOCATION = 0x67737973;` the micro just halts and doesn't go to the nest line which is a reset.

Before I keep fiddling to get this to work, is there a right way to do this?

Thank you,
Samuel

[GromBeestje]

What linker settings are you using for your application. Make sure its RAM doesn't overlap with the magic location.  ( looking at your description, set its size to HSRAM_SIZE-4 )

[cv007]

>is there a right way to do this?

You can start by providing necessary info. What mcu, where is the booloader source code.

Guessing- searching for 'Microsoft UF2 bootloader', it appears you are using a samd51
https://github.com/microsoft/uf2-samdx1/blob/master/inc/uf2.h

#define DBL_TAP_PTR ((volatile uint32_t *)(HSRAM_ADDR + HSRAM_SIZE - 4))
#define DBL_TAP_MAGIC 0xf01669ef // Randomly selected, adjusted to have first and last bit set

https://github.com/microsoft/uf2-samdx1/blob/master/src/main.c

//in app, to reset into bootloder-
*DBL_TAP_PTR = DBL_TAP_MAGIC;
doSoftwareReset();
//notice the pointer is a volatile pointer, else compiler most likely optimizes away

If you use USE_SINGLE_RESET, which we would have no way of knowing, then things change.

No need to come up with additional methods to remain in the bootloader when there is already something in place. I would assume your additional checking got the logic twisted up, or your own pointer was not declared volatile.

[mikerj]

Place a jump table in your bootloader at a fixed address, this could either be implemented as 1) an array of function addresses that you want to be able to call from your application, or 2) a bunch of assembly jump instructions to the required functions.  In your application define appropriate function pointers for each jump table entry and use them to call the bootloader functions, either by reading the function addresses back and assiging them to the function pointers (is using method 1) or calling the function via the jump instruction (for method 2).