Joe Gregorio
You've seen all the warnings when upgrading the firmware on some card, be it your PCMCIA Wi-Fi card, or maybe your MP3 player.
Interrupting a firmware update in progress (i.e. during the firmware upload into the SOMEHARDWARE) may render the SOMEHARDWARE inoperative.
If the firmware upload fails, and subsequent upload attempts prove unsuccessful, the unit may need to be returned to THE COMPANY for service.
I've anonymized the above statement to save singling out a particular company, but I have seen this on a wide range of devices. So what's going on here, why are these devices so fragile?
Here's the basic layout of an embedded system, stripped to just the basics we want to talk about.
The Flash is where the program is stored that the CPU runs. Now it could be either run straight out of Flash, or loaded into RAM before being run. How it's actually used is irrelevant right now. The big problem is how that program gets in there in the first place, and how it gets updated. This tends to be an area that gets overlooked.
How it gets updated is rather fragile, and an incomplete load could end up disabling your firmware. This is actually a rather abysmal situation and can in most cases be completely avoided.
Updating the code is usually a matter of piping a new program image through the running CPU into the Flash memory. This is where the problems start. If the CPU runs off the code in Flash, and the CPU is writing new code to the Flash, how do you avoid disaster? It's like changing your from your shoes into your boots without letting your sock convered foot touch the ground. It's possible, but it requires balance. The same is true with the memory, you can run code, and you can write new code into the Flash, just not at the same spot as the same time.
One strategy is to have a nugget of code that runs in one protected section of memory that can handle uploading new code. That way if a firmware upload fails, this loading code will remain in place and a new upload can be attempted, thus saving your device from becoming a useless hunk of inert electronics. Many Flash devices support this kind of strategy, offering memories that have a lockable region usually at the bottom of memory that can be written with loading code and then locked to prevent it from being overwritten accidently.
But that is only how to upgrade the firmware. How does it get there in the first place? Now if you are a volume manufacturer, churning out thousands of said devices than the answer is simple, you order your Flash from the manufacturer or reseller with your firmware image already preloaded. If, on the other hand, you are a shop that does smaller runs than you need alternative loading mechanisms.
One of the best I have seen is this line of memory chips from ST Microelectronics called PSDs or Programmable System Devices. These chips can incorporate Flash, SRAM, Digital I/Os, a small PLD area, and most importantly for our discussion a JTAG interface. The memory itself has a JTAG interface that you use to program the Flash memory independent of the CPU. In particular they have the DSM2150F5 which is a DSP System Memory (DSM) which contains Flash, Digital I/O, and a PLD and was designed specifically with the Analog Devices Blackfin DSP in mind.
These devices solve the initial program load dilemma along with providing a host of other abilities. In particular DSPs are notorious for not providing enough digital I/O, and placing it on the Flash memory where it can be accessed via memory mapped regions is great. It will be interesting to see what other vendors come up with in the area of programmable system devices.