Best practices for production programming of data/NAND flash devices

Question

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?

Edit:

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.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.