Leverage Flash-Based Microcontrollers To Cut Time-To-Market

March 8, 1999
Flash MCUs Shrink Development Time, While Helping Designers Respond To Customer Needs.

With product life cycles now measured in months rather than years, time to market is more important than ever in the success of a design—especially in the consumer market. Shorter design cycles also translate into less money spent on development and a faster return on investment. But the demands consumers make—more features, smaller sizes, and lower cost—tend to extend design cycles. Reprogrammable flash-based microcontrollers can help designers meet the demands of both customers and corporate bean counters.

Several years ago, a product could be taken from concept to production in a few months. To satisfy their consumer-market customers, however, designers must now integrate more functions onto a single chip and use software to differentiate models. With the level of integration in embedded processors growing and software complexity increasing, design cycles are doubling or tripling.

To compound the problem, device packages are becoming smaller. In some cases, the device die itself is used in the product. These fine-lead-pitch packages and chip-on-board assembly techniques can create roadblocks to emulation and debugging.

But reprogrammable flash-based microcontrollers offer advantages that can reduce the time to market. Flash technology doesn't only shorten the design cycle. It also provides a low-cost emulation solution in situations where none existed previously. Flash-based devices can be reprogrammed more quickly than EPROM-based circuits because flash memories don't require a lengthy exposure to UV light. Plus, flash-based chips don't have to be removed from the circuit board for reprogramming. Just attach a programming cable from the software-development tool to the board (assuming the board is designed for such a capability). Such a scheme eliminates other delays that slow the development process, such as the time for manual removal/insertion, fixing bent pins, etc.

Designers have basically three methods they can use to develop a product: simulation, "burn and learn," and emulation. Simulators for embedded products are typically free or very inexpensive. Usually only the program flow and initialization code can be verified, however. Any interaction with external circuitry is extremely limited.

Simulation can be used in conjunction with the burn-and-learn (BL) approach to speed the debug stage of the application-development cycle. BL typically refers to the method by which the designer programs a device, inserts it into the application, and monitors the operation of the circuit with an oscilloscope or logic analyzer. The way the circuit operates gives the designer clues about the code changes that will be required to make the circuit functional.

EPROM-based processors can lengthen development time because it usually takes 30 minutes or more to first erase and then reprogram the chip with the updated code. One way to speed up that approach is to purchase multiple, EPROM-based microcontroller units (MCUs). That way, the designer doesn't have to wait for one to erase before programming another. But this can be costly and irksome. The MCUs must be housed in more expensive, quartz-windowed packages. And the designer must keep track of which program version is programmed into which chip.

Devices with flash-based, electrically erasable memory can take a big chunk out of development time and cost. Most high-volume applications use an in-circuit programming technique in which the device is soldered into the circuit. It is then programmed through a cable from the programmer. One of the greatest strengths of flash-based devices, though, is that the processor doesn't have to be removed from the application, programmed, and then replaced. This reduces or eliminates the possibility of bent leads and ESD damage due to handling. The designer can still use the BL method, but only needs one device that doesn't have a lengthy erase cycle and doesn't need to be removed from the circuit.

The third development method is emulation. In-circuit-emulator (ICE) tools are the ultimate debugging approach, because they give the designer an "inside look" at the operation of the processor and code. Problems usually can be found immediately using single stepping or breakpoints, and by having access to register contents (both to view and alter). But all this power does not come free.

ICE tools are typically very expensive and have some inherent problems. The probe, which connects the ICE to the application, usually has some type of ESD or other circuit-protection devices that can interfere with the circuit's operation, often slowing it up. Also, the probe is connected to the circuit via a cable or other interconnect that introduces capacitance and loading effects on both the application circuit and probe. This is most apparent in an analog circuit, where the processor has an analog-to-digital converter (ADC).

Still another issue is that the probes support a limited number of package types. Dual-in-line and plastic-leaded-chip-carrier packages (DIP and PLCC) are most prevalent because the probe can be connected to the corresponding socket in the application. Small-outline IC adapters that are soldered onto the application's printed-circuit board are also readily available, but are often quite costly.

The fine-lead-pitch packages like shrink-small-outline and quad-sided flat packages currently are not supported by most probes. And even smaller approaches like chip-on-board (COB) and chip-scale-packaging (CSP) schemes present still more difficult, if not impossible, challenges to probe attachment. Such schemes push the designer into a corner in which flash-based processors and BL techniques are the only viable solution.

When using fine-lead-pitch packages or COB approaches, an extra step may be used in the development process. Simple applications can usually go right to the surface-mount design, but more complex applications require emulation. Since no emulation solution is available for these package types, a designer would first perform most of the debugging and development with a leaded prototype. Then, for production, the designer would switch to the surface-mount design. In this scenario, emulation needs have been satisfied. But cost and time-to-market have grown because of the extra prototype step.

Consider a consumer product such as a carbon-monoxide detector. Such a product is extremely cost-sensitive and will typically be designed around an MCU. In the past, carbon-monoxide detectors usually used a packaged MCU instead of a bare chip or CSP. But a significant portion of the cost of the MCU is in the package. So, to trim cost, it would be nice to use some form of COB packaging. If that chip is a flash-based MCU that allows in-circuit debugging, the designer can eliminate the extra leaded-prototyping step.

One further improvement in the development cycle would be to combine the advantages of flash with the flexibility and strength of an ICE. Several manufacturers have developed a debugger in conjunction with their flash-based processors—sort of a middle road between an ICE and the BL method. A debugger, however, offers the flexibility of an ICE. It even overcomes some of the inherent problems at an affordable price.

The main advantage of a debugger is that the device itself is the emulator. The debug circuitry is already on each processor. Thus, the designer benefits by having an interface to the external circuitry that will behave exactly like a real device. Such a feature is very important when it comes to I/O drive strengths, ac timings, and oscillator operation. There are no protection devices to interfere with the operation of the circuit and no cables or interconnect devices to load the circuit.

One such debug system consists of the MPLAB-ICD In-Circuit Debugger, which is based on the 8-bit PIC16F87X family of MCUs. These devices are flash-based, with up to 8192 by 14 words of program memory, 368 bytes of data RAM, and 256 bytes of data EEPROM. Peripherals include a 10-bit ADC, a USART, an I2C interface, an SPI port, pulse-width modulators, and more.

The first key block in the debug system is the MPLAB-ICD module, which interfaces the host PC and the PIC16F87X (Fig. 1). The module receives new code from the PC and programs it into the target processor. This module also controls the Run, Halt, and Single-Step debugger operations.

The second part of the system is the MCU. In this example, a PIC16F877 mounted on a DIP header is used. The header can be plugged into the application's circuit board. Actually, the header could be any packaged version of the chip. And the designer need only provide five basic connections between the MCU and the MPLAB-ICD module: MCLR/VPP, VDD, VSS, RB6, and RB7. These are the same connections that provide in-circuit system programming (ICSP) for the chip. Thus, any circuit that's already configured for ICSP is ready for in-circuit debugging. This in-circuit-debugging approach also overcomes the last issue with ICE systems: the need to emulate devices in fine-lead-pitch and COB/CSP surface-mount packages.

An engineer must recognize that all designs go through the same life cycle, from an idea on a napkin to a manufactured product. For most products, the designer can choose from among the different memory technologies to optimize cost in each of these phases.

All products, however, can be brought to market faster and less expensively by using flash-based devices during development. Once the product is ready to manufacture, the designer can opt for one-time-programmable (OTP) devices to reduce cost even further (Fig. 2). OTP-based devices are cheaper than most flash-based MCUs, since they're based on EPROM technology. They also have a considerably shorter programming time than flash devices.

During the initial manufacturing phase, the designer may want to add features or fix some bugs. By using ICSP, OTP devices can be programmed on the manufacturing line with the latest version of firmware, ensuring that customers receive the latest release of the product. Once the firmware has matured, manufacturing can transition to a ROM-based processor if system sales are expected to ramp up. That would eliminate the programming step and further reduce manufacturing costs.

Near the end of the product's life, a manufacturer may want to switch back to OTP devices. This helps service the remaining market, while lowering its processor inventory. The key to success in migrating between memory technologies is ensuring that the flash, OTP, and ROM processes maintain the same I/O drive strength, ac timings, oscillator characteristics, etc. In other words, they must be totally pin-compatible and transparent to the system user.

Although flash-based processors have proven their benefits for prototyping and development, they aren't an economical manufacturing solution for all applications. The programming time alone—which for the flash-based MCU family is 2 ms per byte or per word—presents a serious manufacturing issue. In comparison, an EPROM memory array can be programmed at a speed of about 10 µs per byte or per word.

So if a processor has 4 kwords of memory to be programmed, a lone device programmer can program about 3500 flash-based devices in an eight-hour day. That assumes the line can run non-stop, including zero time for device changeover. The real world typically demands 0.5 seconds for the automated changing of the device in the programming socket. That drops the throughput to about 3300 devices per day. In the same eight-hour day, a perfect manufacturing line can program about 703,000 equivalent-size, EPROM-based processors. Even with 0.5 seconds added for each processor for changeover, the practical throughput is just over 53,000 MCUs per day.

Every designer would like to have a system that's field reprogrammable, but many issues affect that decision. The need for fault-tolerant communications during reprogramming and the cost of labor to upgrade the system are just two.

One example of an application that is ideal for flash-based processors is the automobile. Cars typically have service lives of more than 10 years. When a vehicle is brought in for service, the technicians have to upgrade an electronic system, like the engine-control module (ECM) as part of the service. Generally, the ECM is removed and replaced with a newer version. Maintaining an inventory of ECMs and the technician's labor to replace the ECM are both expensive. If the vehicle is under warranty, the car manufacturer absorbs these costs. Otherwise, the customer is left to pay the bill.

If the ECM incorporates a flash-based processor, however, the technician simply reprograms the ECM in a very controlled environment. This drastically reduces the cost of service and eliminates the need to stock expensive ECMs.

The primary savings from flash-based processors come in the form of reduced development time and easier debugging of the product. While some applications can benefit by employing flash MCUs, the designer must weigh the manufacturing and operational issues involved when choosing the memory technologies.


To join the conversation, and become an exclusive member of Electronic Design, create an account today!