Design criteria for 32-bit ECU upgrade

There are multiple design issues to consider when contemplating the move from a 16-bit microcontroller to a 32-bit device. One way to better understand the process is to consider what's involved in the design of an automotive engine control unit (ECU).

Over the past two decades, engineers have upgraded ECUs by making the switch from 8-bit microcontrollers to 16-bit devices and beyond. In today's ECUs, a high-speed 32-bit controller is essential in light of such system requirements as handling the expanding levels of I/O, communicating with other in-vehicle systems via "safety-critical" communication links (such as CAN and Flexray) and processing algorithms with floating-point precision.

At Renesas, our processor road map is intended to match the evolution of ECUs. While delivering major advances in capability, the newest 32-bit MCUs also reduce board design complexity, save overall pc board space, decrease system power requirements, reduce electrical noise and lessen susceptibility to electromagnetic interference. Typically, each ECU costs around $70 to $100 to manufacture. The microcontroller accounts for about 15 to 20 percent of that total.

Systems that use 32-bit microcontrollers typically are extremely complex, and an ECU project generally takes about two to four years to complete. Design teams usually consist of one or two hardware engineers and four to five software engineers. For the best chances of success, all milestones and resource requirements must be correctly identified, and the design flow from concept definition to production must be agreed on from the outset.

Project plans should identify the design environment, particularly the development tools, and should include test and debug plans.

A key goal early in project development is to identify what will be implemented in hardware and what in software. This decision is influenced by such factors as the engineering budget, component cost, board space and deadlines. Trade-offs are inevitable. In ECU design, extensive algorithm modeling and system simulation are needed to achieve the optimum design partition. The good news is that several vendors offer products for resolving partitioning issues.

Software issues
Software engineers confront many decisions when developing 32-bit systems. In the case of an ECU, if proven code from previous designs can be reused, time will be saved and the workload reduced. Most embedded designs use C, allowing a high degree of code reuse. Porting the old code, however, requires changing peripheral drivers and code sections that relate to items specific to the MCU architecture. We recommend using device-driver code-generation tools, such as IAR's MakeApp, which can save many hours of engineering time.

Other important issues related to the code development effort cannot be overlooked, such as selecting the right real-time operating system and debug scheme. Many papers and articles have been written offering advice on RTOS selection. For ECU designs, OSEK has evolved as the industry-standard RTOS. This deterministic, robust, efficient and reliable solution is available from multiple vendors. Software engineers should also try to ensure that they will have sufficient debug capabilities when the project gets to the integration stage. Despite the fact that code simulators are very good, integration problems are a certainty.

So what's needed? The answer varies. In the case of an ECU design, full-speed traditional in-circuit emulators (ICEs) are expensive-about $12,000-and are difficult to use in an engine bay, but they're unmatched for solving tricky timing problems. By contrast, on-chip debug (JTAG-style) emulators are economical, at around $1,000, and are far easier to connect to a system.

Renesas' E10A emulator, for example, is a JTAG-compliant hardware debugger that lets the hardware engineers interrogate and control the register set and RAM memory of a SuperH processor. Moreover, to enhance the quality of the ECU code, the software engineers can take advantage of a special debug feature that provides a limited trace of the SuperH CPU pipeline. The debug interface on the MCUs in the Renesas SH7058 MCU family is bidirectional and allows RAM to be written to without halting the CPU. This feature is necessary for ECU calibration.

Hardware issues
Of the myriad hardware issues that arise during the development of 32-bit systems, power supply filtering and on-chip flash memory warrant special mention. Most 32-bit microcontrollers run much faster than 16-bit devices. Moreover, the CPU core of the 32-bit MCU core may need its own low-voltage power supply, one that is quieter than what will suffice for the I/O circuits. We stress that it's good practice to provide adequate low-frequency and high-frequency decoupling capacitors around the board, especially near the MCU.

In the past, many microcontrollers used in ECU systems did not contain enough memory to operate as a single-chip controller, and some had no program memory at all. As a result, the program memory had to be located off-chip. Often that led to EMI problems because of the many high-speed address and data bus lines that were required. Today's 32-bit ECU is moving to a true single-chip solution, with devices like the SH7058, which has 1 Mbyte of flash memory. In most cases they provide enough on-chip program memory to eliminate the need for off-chip memory.

In an ECU design that uses the SH7058, the on-chip flash memory can be programmed either by a device programmer before board manufacture or in-system after the board has been built. Software engineers thus have a great deal of flexibility for updating the code. They can even perform updates via the vehicle bus (CAN) after the ECU has been installed in the vehicle.

Making the jump from a 16-bit to a 32-bit MCU is a big step but hardly a forbidding one. The 32-bit implementation will deliver huge boosts in system capabilities and performance. Key aids to successful transitions are adequate preparation and training and astute development tool selection, plus solid support from a 32-bit microcontroller vendor.

Tim Dry is segment marketing manager at Renesas Technology America Inc.

See related chart