Firmware upgrade - Page 1
Forum section: electronics / general

author: Christian
author_rank: Newbie
timestamp: September 07, 2018, 07:51:03 pm
content: Hi allI seek some inputs / inspiration on a firmware upgrade project I am working on.First a little background information. The project is based on a Microchip (former Atmel) chip from the SAMV series (300MHz, 2MB flash, ~400kB ram). The firmware is written in C. The devices are to be deployed remotely and will have to accept firmware upgrades Over The Air. As a fallback (if the OTA upgrade fails), it shall be possible to upgrade by accessing the device physically. First, I will focus on the upgrade process and later the security related subjects, such as firmware encryption and signature. For now, I seek inputs on the firmware upgrade only. The device runs a bootloader and a main application. The bootloader will implement the firmware upgrade when an image is ready. The application can pull new images OTA. The device has a SD-card installed which is used by the application and formatted using FAT32.Currently, my plan is the following (with a lot of missing details):1. When the application is running, it can receive new firmware OTA. The firmware image is "somehow" made available to the bootloader, and the system is reset such that the bootloader can flash the new image. For now, I am not sure if the application should place the image in the internal flash (wasting a lot a flash) or on the SD-card. By placing the image on the SD-card, half of the internal flash does not need to be reserved for firmware images. The disadvantage is that the bootloader becomes more complicated, as it needs to communicate with the SD-card. More on the SD-card in #3.2. When the OTA firmware fails, the bootloader will have to be able to accept images directly. I hope to be able to do this using the SD-card to avoid any additional external interfaces, USB drivers etc. The bootloader has to be as simple as possible to reduce the risk of bugs. Ideally, it should not need to know FAT32 - but only need to read raw sectors from the SD-card. The MCU impements a SD-card interface in hardware, which makes the communication with the sd-card fairly simple.3. When using the SD-card for image storage, the image can either be placed "directly" on the SD-card or using the FAT32 filesystem. By placing the image directly on the card, the bootloader does not need a copy of the filesystem - which makes it much simpler. The disadvantages are: 1. the application uses the filesystem and the content cannot be deleted during firmware upgrade, 2. using the fallback method (with physical access to the device), the SD-card shall be "flashed" with the image using some sort of image flashing tool (e.g. etcher?). Maybe an option is to use two partitions on the sd-card, one for images (without filesystem) and one with a filesystem - then the bootloader can simply read from the first partition, without filesystem.I hope above makes sense. Any feedback is highly appreciated.I have a few additional specific questions:- When a SD-card is partitioned, how is the partition headers formatted? I guess the bootloader will have to be able to parse the partition structure. I have not been able to find specific documentation on this. I will appriciate if you know of any similar applications you can refer to.- When using an image flash tool (as e.g. used for flash of raspberry pi image), it seems that multiple partitions are created, which are flashed with the binaries. I have not been able to find documentation on the *.img format or any tools used for creating such files. If a create a binary firmware file, it seems not to be accepted by sd-card flashing tools (such as etcher).Looking forward to your replies.ThanksBrChristian

author: technix
author_rank: Super Contributor
timestamp: September 07, 2018, 08:08:04 pm
content: Here is an idea since you have a microSD card available almost at all times:1) The application can implement either a server push mechanism or a periodical poll, so it is notified of OTA updates on a timely manner.2) Before writing anything to the internal Flash, write the update contents to the microSD card first. Also do not delete the old firmware image before the new one successfully booted, so a botched update can always be reverted when watchdog fires.3) Since you are likely going to use a fairly big bootloader anyway, it might be a better idea to use a chip that is capable of big RAM capacity and/or big external RAM, and keep functional firmware in RAM. This makes recovery that much simpler, since once watchdog fires you know your update is botched, and there is no code to erase for recovering from it. This can even enable some ridiculous firmware image sizes (a 48MB firmware image maybe, for a chip with 64MB external SDRAM.)4) The partition table structure is standardized. Just follow the standard and you will be able to decode it. You can even use them for your own advantage: one partition for firmware images, one for application data.5) The partitions created when an image is flashed to an SD card is already there in the source image. If your image comes with just one partition it would work just as well.6) Employ TLS and HTTPS for this process - it protects your IP from being eavesdropped, and the TLS client certificate authentication feature can also give you product activation and anti-theft features with a simple rule on device (using the general idea of always-online activation) and a little bit of server work.

author: Christian
author_rank: Newbie
timestamp: September 11, 2018, 10:41:19 am
content: Hi technixThanks for the reply and your suggestions.To simplify the update process, I have decided to include a minimal read-only FAT FS + SD-card driver in the bootloader. This makes the handling of the SD-card much easier.BrChristian