2018-06-08 07:22 AM
I'm looking to do some firmware updates over CAN bus on an M0 based part (possibly F091) which it looks like will require a custom bootloader. Do I need to pick a part with enough RAM to store the entire firmware image so I can transfer the image to the bootloader and then write it to flash? Or I there a way to transfer directly to flash to eliminate the requirement of the RAM being able to hold the entire image?
#stm32-can-bootloaderSolved! Go to Solution.
2018-06-08 08:44 AM
The more realistic approach is to have a small boot-loader than can update the larger application portion of the FLASH in the absence of more RAM, or off-chip memory to stage the new firmware image.
If you have enough memory to handle 1KB blocks, update the firmware in 1KB pieces, and create an update protocol that facilitates that.
You could also use a device that has twice as much FLASH than your app needs, or perhaps compress or delta images
2018-06-08 08:44 AM
The more realistic approach is to have a small boot-loader than can update the larger application portion of the FLASH in the absence of more RAM, or off-chip memory to stage the new firmware image.
If you have enough memory to handle 1KB blocks, update the firmware in 1KB pieces, and create an update protocol that facilitates that.
You could also use a device that has twice as much FLASH than your app needs, or perhaps compress or delta images
2018-06-08 12:16 PM
I don't think the flash will be the issue since we should have more than twice the amount the app needs, but the RAM is limited to 16kB. So what you're suggesting is to make a bootloader that is able to accept the new fw image in chunks of maybe 1kB, buffer that in RAM, write it out to FLASH, and repeat until the whole image is transferred?
I suppose with the extra flash available we could keep the previous version check for a CRC or similar to validate the image before booting it as well.
2018-06-08 12:47 PM
Well hopefully your current loader is validating the app before running it. If the app is invalid it should fall back to a recovery/download mode, or be minimally functional. The idea being to create something robust that isn't going to brick itself. In most cases you shouldn't need to update the loader in the field.
CAN is somewhat constraining in it's packet size, but you should certainly be able to accumulate blocks of data in RAM and be able to write those out to areas of the FLASH
2018-06-08 12:59 PM
Well we're currently still selecting the part so we have no bootloader at all yet but that makes sense. Does the default bootloader verify the image?
2018-06-08 01:53 PM
The ROM based System Loader doesn't usually run or get involved. User code in FLASH is mapped so the CPU just starts and runs it. Integrity checking would need to be implemented and checked at the user level.
Most of my devices can be updated via the serial port, we use X-MODEM-1K as this is supported in everything, so there is a CRC on the packets, flow control, and then the firmware image has a longitudinal 32-bit CRC