A project has finally reached the point where prototypes are operational and ducks are lining up in rows for the first pre-production lot of boards. It uses a SOC device that boots its ARM core from an external NAND FLASH chip, which normally contains a boot loader, the embedded application, and other data resources. With a minimal boot loader and application in FLASH, it is easy to field upgrade. The prototypes got boot loaders installed with a JTAG cable, but that seems more than a little unwieldy for production lots larger than a dozen or so boards.

If this were a NOR FLASH or OTP PROM I would expect a vendor to be happy to take an Intel HEX or Motorola SRecord file and deliver devices that just work when soldered down.

Given the different nature of NAND FLASH devices, what issues should we be watching for? What questions should we be asking vendors? What form of image should we be expecting to be able to supply?

In short, what is the usual practice for pre-programming a NAND FLASH device before assembly?


If it were to make a difference, it is an STM (numonyx or micron, why can't the chip companies stop selling each other their product lines mid design cycle?) NAND512xxx 512 Mb SLC family device that wants programming.


The trick here is PogoPins (Wikipedia)

Basically you make a jig where you drop the board in often descriped as a Bed-Of-Nails In-Circuit Tester/programmer, and it's then flashed without having to deal with the connector-mating aspect of the jtag interface.

LadyAda did a tutorial, and so did SparkFun

  • \$\begingroup\$ I've done things like that before. We were really hoping not to have to include JTAG in the factory bring-up process this time, however. \$\endgroup\$ – RBerteig Oct 8 '10 at 6:44
  • \$\begingroup\$ The clamp idea is really clever. \$\endgroup\$ – Connor Wolf Oct 8 '10 at 7:52

It turns out that the distributor has figured out that they can perform this service on loose parts before delivery to the assembly house. I'm personally not involved in the purchasing process, and can't begin to guess how much (if anything) this increased the cost of the parts.

We had to produce a file containing a copy of every bit to be programmed including the 16 extra bytes per page, with the extra bytes properly formatted with the ECC and bad block information structure that matches the assumptions of the NAND driver, and with all unused blocks (and their extra bytes) left blank. The file was as large as the device, but ZIP had lots of leverage for compression.

Along side that, we had to produce a table of base addresses and expected sizes of the partitions in use in the device.

Apparently the Data I/O FLASH programmer will verify each page during programming, mark pages that fail as bad, and automatically retry on the next page. This requires that the partitions have enough spare space to allow for some bad pages. The part will be rejected if a specified number of pages are bad, or if a partition won't fit.

Our first batch are in process based on an image dump of the live chip in a prototype unit. Our plan is to improve on that by writing a tool that can produce the necessary image on demand or as a final build step.

  • \$\begingroup\$ spot on method for doing it. Most distributors will offer this service directly or through an associate company, offer laser engraving (normally free) of the part, and re-reel to suit your manufacturer. \$\endgroup\$ – smashtastic Nov 1 '10 at 8:46

When I've done similar things, I've always programmed the SoC with JTAG (or a gang programmer) then had the ARM core format and program the NAND flash (being fed data over serial or ethernet).

This way, the software can map out any bad blocks in the NAND.

  • \$\begingroup\$ So the issues with bad blocks make it simply not practical to get the NAND pre-programmed in bulk? That is plausible, but unfortunate. \$\endgroup\$ – RBerteig Oct 8 '10 at 6:45
  • \$\begingroup\$ You may well be able to buy NAND with no bad blocks. It's worth asking your supplier. \$\endgroup\$ – Toby Jaffey Oct 8 '10 at 8:11

One possible way to avoid the bad block issue may be to have just a minimal bootloader in the initial guaranteed error-free area of the NAND, and have this program the main content via whatever interface the product has available during test. e.g. temporarily connect a SD card or something.

Another option if you have plenty of space in the NAND is to preprogram multiple images, and have the processor derive a good image from these images the first time it powers up.

It would be worth talking to companies who already offer programming services, as they may have already found solutions to this.

  • \$\begingroup\$ All true, but my question is really about the production process: how do I arrange things so that on first power on a newly assembled board has enough software available to run self tests and reflash to a final version of the firmware. \$\endgroup\$ – RBerteig Nov 1 '10 at 18:54
  • 1
    \$\begingroup\$ You get the NAND preprogrammed by a programming house. Keeping the preprogrammed part to a minimum, in the guaranteed-good area, means the programming house doesn't need to deal with whatever bad-block system you are using. I don't know how standardised ECC algorithms are though - particularly on multi-level, I suspect even the 'guaranteed good' area may only be guaranteed with ECC. \$\endgroup\$ – mikeselectricstuff Nov 2 '10 at 0:25
  • \$\begingroup\$ They asked us to supply the image to program including all of the ECC bits, and they agreed to write a specific value to an offset in the extra bytes to mark pages that are not bit-identical with our image. Their default value and offset matched our SOC vendor's boot loader's requirements by "coincidence". I assume they agreed to discard any chip where block 0 page 0 was bad. \$\endgroup\$ – RBerteig Nov 2 '10 at 19:06

The most versatile approach, though I don't know if anyone supports this, would be to have a chip programmer read a chip and write it to a file, then run a user-supplied program to update the file with what should be in the chip, program the resulting file into the chip and read it out, and run the user-supplied program to verify it (possibly repeating the program cycle if the verify program wasn't satisfied with the result). When that isn't practical, I would think the best approach is often to simply have a means of feeding the required data into the target circuit so it can program the memory chip using whatever forms of error-correcting and bad-block memory it uses.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.