Cortex-M0: How to switch from one program to another

Hi fulgor3.

It all looks reasonable to me. I have not written a bootloader myself yet, but if you're writing code for the Cortex-M0+, Cortex-M3, Cortex-M4 or Cortex-M7, then it should be very close to the procedure you expect above.

The location and size of the boot code depends on your device (however, I would expect that the location would always be 0x00000000, since that's the default value of VTOR!).

Remember that most (all?) Cortex-M have a built-in ROM-bootloader, which is run first. This bootloader can in most cases be "bypassed", but as it's always executed, in order to determine if it should run any code, I would expect at least 3 instructions would be run from the ROM bootloader on each cold start.

If you're writing a bootloader for private purposes, it might be a good idea to support booting from RAM (eg. if you do a lot of testing, then you don't need to wear down the flash-memory. Personally, I've never worn down any Cortex-M's flash memory, even though I've been flash-programming the same device several times  per day, but if you're doing some automated tests, you might want to consider using the RAM.

If you get fancy, you could also try embedding the LZ4 decompressor in your bootloader (it'll work on all the Cortex-M architectures (and some earlier architectures as well).

Hi fulgor3.

It all looks reasonable to me. I have not written a bootloader myself yet, but if you're writing code for the Cortex-M0+, Cortex-M3, Cortex-M4 or Cortex-M7, then it should be very close to the procedure you expect above.

The location and size of the boot code depends on your device (however, I would expect that the location would always be 0x00000000, since that's the default value of VTOR!).

Remember that most (all?) Cortex-M have a built-in ROM-bootloader, which is run first. This bootloader can in most cases be "bypassed", but as it's always executed, in order to determine if it should run any code, I would expect at least 3 instructions would be run from the ROM bootloader on each cold start.

If you're writing a bootloader for private purposes, it might be a good idea to support booting from RAM (eg. if you do a lot of testing, then you don't need to wear down the flash-memory. Personally, I've never worn down any Cortex-M's flash memory, even though I've been flash-programming the same device several times  per day, but if you're doing some automated tests, you might want to consider using the RAM.

If you get fancy, you could also try embedding the LZ4 decompressor in your bootloader (it'll work on all the Cortex-M architectures (and some earlier architectures as well).

Hi jensbauer,

Thank you for your fast response.

I didn't know Cortex-M have a built-it ROM bootloader, reading the ATMEL SAM R21 ( The ARM CORTEX M0+ MCU I am using) datasheet I only noticed that there is a FUSE called BOOTPROT (I haven't used a FUSE before, so I don't know if it must be set up using the JTAG or maybe writing flash memory position directly. I say this because there is a lot of references to Non volatile memory when BOOTPROT comes up) to set aside some memory for the BOOTLOADER in the lower rows of the NVM.

Booting from RAM? I haven't done this before, is complicated? It could be great, but I need to develop something similar in a 8051 architecture, so I have some RAM constraints, and I hope that just few applications updates will be required in the future .

The LZ4 decompression routine for Cortex-M0 and later sounds great. It is used to compress the data to be send to the bootloader in order to decompress it to get the final modifications or for the bootloader's code itself??. I will study it. If I get performance improvement it would be really welcome.

Again, thank you very much, and any support will be really appreciate.

Best regards,

Iván Gómez Bustinduy