In today’s market we have a choice of different types of flash memory devices – or, many of us might say, we have different devices that we can flash. We have NOR and NAND and then there is SPI. Each platform we adopt as a reference design to take advantage of some new hot processor also recommends what tool we should use for programming its flash. And, of course, it’s not a programmer in your arsenal of tools. So off you run to get Yet-Another-Programmer (YAP).
Of course these YAPs have their limitations on which devices they support or how to connect to the flash memory devices. You’d probably want to visit the connection methodology and see how it’s going to work in the lab. Then the fear overtakes you as you contemplate how to address the needs of manufacturing at your CM, given the limitations of your YAP. If you have high-volume production, you’d naturally want to preprogram your parts, but then there is always the dreaded firmware “upgrade”, which means they finally fixed the bug you reported a couple of days ago. Unfortunately, the upgrade negates all those preprogrammed parts you have. Hopefully they were socketed and not soldered down. If you have low-volume production, you’d probably want to know if the programmer is robust enough and simple enough to use on the production floor. So begins the list of questions that you have about every new flash device and its YAP.
Next your mind might turn to thoughts of what file format the programmer supports as input. SRecord, Intel Hex, ELF, DWARF, binary or – heaven forbid! – BCD. What about the image your software team is providing? How is it broken up? You might do a little digging on NOR flash, NAND flash and SPI flash just to satisfy some morbid curiosity of how a certain type of device is actually programmed. In this connected world, don’t forget those pests that contain the MAC (Media Access Control). They seem to be everywhere. As a result, we have to deal with EEPROM, CPLD, PLD and FPGAs in addition to pure flash devices. Pretty quickly you end up with a nice assortment of problems and YAPs.
One good thing is NOR is pretty straight forward. Figure out which lines to set up, set up the data, clock a few clocks or loops for a done bit and then move to the next data element. How big an element does the device support? Does the device have any special programming modes? As for NAND, you’ll have to calculate the FAT tables much like those on a HDD. And each programming sequence needs to write the data and update the FAT. Don’t forget to account for bad sectors and map the sectors out of your programming routine. Of course, SPI is serial so it’s real easy, but what about the distribution of the data? Map the wrong data to the wrong area and the CPU or some other device prevents the board from functioning.
Why not skip all these headaches and use the best instrument that’s already embedded on your board for the job of in-system programming? The best all-around instrument is the CPU. All you need is access to its debug port and ScanWorks Processor-Controlled Test. Use it in the lab, in production, in the field and at CPU speeds. It supports NAND, NOR and SPI programmatically or interactively. Check out a movie here.
