Written by Brian Hammill
Atmel, along with a number of other industry heavyweights, recently introduced a slew of Cortex-M microcontrollers (MCUs) equipped with a dual-bank flash feature. While single bank flash is sufficient for numerous applications, the dual-bank feature offers significant value in specific scenarios. So let’s discuss the added benefit of dual-bank flash.
Dual bank flash provides a fail safe method of implementing remote firmware upgrades
First, we need to understand the role of flash in a MCU. Just under 100% of the time, the flash memory in your MCU is in read mode. The processor core is almost always fetching instructions to execute out of the flash. Exceptions? When code is being run from RAM, internal or external, or ROM. Meaning, with typical flash memory, you cannot read while you are writing to it. As such, during firmware upgrades and data storage operations, the processor core cannot execute code from the flash. Either the processor has to wait for the write operation to complete, or the core can continue to execute from other physical memory such as RAM or ROM.
In Atmel’s single bank SAM3 and SAM4 family flash MCUs, this problem has been solved in a somewhat novel manner by providing flash programming code in the factory programmed ROM. This means that whenever the firmware engineer wants to write the flash, it will buffer the data to be written and make a call to a routine in ROM. The processor core will then be executing from ROM while the flash is being written. Since flash erase and programming operations can take milliseconds (a very long time for a MCU core running at up to 150 MHz), the ROM routine may have to sit in a do nothing loop while the flash operation completes.
Admittedly there are limitations, but this method generally works just fine for systems with external storage such as serial flash – retaining downloaded firmware images until they can be written to the internal flash. It also works well in systems which infrequently write a few bytes of data to the flash.
Firmware upgrades can be risky, especially in applications where firmware images are downloaded across slow unreliable wireless links – or where systems are prone to power failures. In a single bank flash system, ensuring a reliable firmware upgrade means there is a part of the flash that you never erase or write over. The code contained in that part of the flash knows how to detect corrupted code in the rest of the flash.
Using a checksum, CRC, or even a digital signature are common ways to determine the validity of the flash image on boot or reset. If the check comes out bad, the code in the part of flash that is never over-written knows to look for a backup image and attempt to reprogram the application. The backup image can be located in an external memory such as a serial flash or if there is enough space, in an unused part of the internal flash.
Managing backup images in internal flash or external serial flash can be done reliably in a well planned system with single bank flash. The key is well-planned, although the firmware engineer has to jump through some hoops because changing the interrupt table ordinarily means you have to change the very lowest flash addresses. Plus, you cannot keep that part of flash unchanged over the life of the product in the field. So it is necessary to have the fixed interrupt vectors point at defined locations where the actual interrupt service routines are located. And finally, the actual ISRs can be changed when the application is changed by a firmware update, although this can lead to size restrictions or wasted flash space between the ISRs.
Atmel | Bits & Pieces 