What worked yesterday doesn’t always apply to today’s programmable memory devices in communications products. Sometimes, these devices can be a major manufacturing problem. But our experience has shown quite the opposite—these devices, if they are flash and not just PROMs, can be real assets.
Gandalf has been producing data communications products for 20 years. This application centers around the company’s line of next-generation equipment that interfaces an Ethernet card with a phone company’s ISDN lines. It can be connected to an ordinary telephone.
In the past, microprocessor-based communications equipment stored the software in UV-erasable or one-shot PROMs. In the manufacturing environment, that meant each device had to be programmed and correctly labeled. Software upgrades required the physical replacement of these PROMs.
In our case, the communications market demanded the capability to upgrade the product’s application software in the field; that is, no more EPROMs. This decision turned our focus to the flash device, which provides permanent storage capabilities and allows you to update the software without opening the product.
The cost of flash vs EPROM wasn’t the issue. The market had stated a preference for flash-based products.
It’s Not All Roses
On the surface, it may seem that flash devices haven’t done anything to help the manufacturing process. You still have mountains of devices to program and label. So what’s the big deal?
Consider this manufacturing process: Instead of programming the flash devices in the programmer, install blank devices in the product and have the product program them.
From our experience, we know that a small boot device can download application software from a file server to flash memory. Then the product can operate as if it contained traditional PROMs, saving the time and effort that would have been spent hunched over the commercial programmer.
The next hurdle is getting the software into the product. This requires intense cooperation by engineering and manufacturing to develop the software and processes to get the job done. Essentially, this is a product-management issue and each company will have its own problems to resolve in this area.
How We Did It
In our ISDN remote-access product, the user data port is Ethernet based. The boot requirement is actually fulfilled by using a boot-sectored flash device. These devices have a portion of the flash device that can be hardware-protected against erasure. This means that only the boot portion of the flash needs to be programmed on the commercial programmer.
The software is automatically downloaded during the manufacturing burn-in phase of the product. On power-up, the product in the burn-in rack performs a built-in self-test (BIST) for all of the major functional blocks (Figure 1).
Once the BIST is successfully completed, the product performs a cyclic redundancy check (CRC) test on the flash devices. If the CRC test fails, the unit assumes the flash is blank and attempts to contact the file server to request the required files.
The actual file name is based on a series of option straps on the unit. This allows software variants to automatically download the correct files by simply changing the option straps.
The addresses for the server are hard-coded and the product’s Ethernet address is based on the product’s media access control (MAC) address. The MAC is a number that each manufacturer must put on any network-based communications product. It identifies where a data packet originated, such as a return address on an envelope.
The MAC minimizes the possibility of duplicate Ethernet address requests. There are more elegant network solutions to this problem, but our remedy was quick to develop and works quite well.
If this product didn’t have an Ethernet or other high-speed network interface, then a serial port could be used. This would require the use of a serial data switch and software to implement an Xmodem or similar download protocol. Basically, the Xmodem transmits the message in blocks that also contain a checksum. The computer at the receiving end verifies that the block of data received produces the same checksum.
This situation is not nearly as desirable as the high-speed network connection, but it still could be implemented. The only downside would be the serial network. The length of time needed to download isn’t a consideration because this process happens unattended.
More Flash Advantages
Our product has three 4-Mb devices. The total downloading and programming time is 40 s using the BIST software. The time required to program the boot section of just one device is 45 s on the commercial programmer.
Programming these high pin-count surface-mount devices on a commercial programmer is very frustrating. It requires very precise positioning of the IC legs (very sensitive coplanarity problems). The less these devices are handled, the better the product yield will be. Obviously, your mileage depends upon your programming/handling equipment.
Suffice it to say that the BIST software that downloads and programs the flash within the product performs faster than the commercial equipment we are using to program the boot sector, and minimizes the contacting problems.
How many times has a mandatory software upgrade caused a work-in-progress nightmare? In the old days, it meant removing, erasing, reprogramming, relabeling and reinstalling the EPROMs. This process was time-consuming and prone to error.
With flash devices, a software upgrade can be as simple as changing the files on the server and reprogramming any units beyond the burn-in stage. This process can be easily automated so thousands of units can be quickly updated by a handful of people.
No more sockets for application software. I’m sure most of us have had the bad-batch-of-sockets problem more than once. Bad sockets are one of the major causes of DOA products. Any time you eliminate a socket from a product you will save money and future problems.
Summary
For our company, flash memory devices provide a variety of benefits: The demands on the commercial programming equipment are substantially less. Only the boot device requires location and labeling. The handling of delicate raw materials is reduced and the cost of customer application programming is “free.” Software upgrades are much easier and the sockets for the software disappear altogether.
About the Author
Fred Roberts joined Gandalf as a co-op student 16 years ago. Today, he is a Senior Test Engineer at the company. Gandalf Canada Ltd., 100 Colonnade Rd., Nepean, Ontario, Canada K2M 7L4, (613) 723-6500.
Copyright 1995 Nelson Publishing Inc.
June 1995
|
|