The number of microcontrollers in vehicles is increasing steadily, and one of the key areas in which they are being used is to reduce fuel consumption. Therefore, some manufacturers are designing and manufacturing microcontrollers aimed at powertrain applications. The trend in this market is to distribute the intelligence around the vehicle. Such microcontrollers are able to tackle the different aspects of the powertrain and the networking challenges of a distributed architecture.
Microcontrollers used as the engine control unit (ECU) are becoming more prevalent. Confirming that these will do the job needed and are of the highest quality is paramount in fostering further implementation. Diagnostic tools are required to analyze traceability information, so this type of first-level diagnostics should be carried out as early as possible in the design cycle.
The powertrain market is searching for innovations to reduce the carbon footprint of vehicles, with popular methods including the downsizing of engines, reducing injection losses, and increasing efficiency. Carmakers want to optimize the gear ratio and gear shifting, reduce friction and hydraulic losses, and continue the push towards hybrid and fully-electric vehicles. In all of these areas, the electronics in the car play an increasingly vital role.
Examples and applications
Putting these ideas into practice are a number of devices, starting with the STMicroelectronics SPC563M64L5COAR, part of its SPC56x range of microcontrollers and suitable for ECU diagnostic applications. The Infineon SAA-XC866-4FRA 5V BE can also be used in various powertrain applications (an example of its ability to reduce fuel consumption when used as part of the circuit controlling a fuel pump will be discussed later). Atmel’s AVR low-power 32-bit microcontrollers, such as the AT32UC3C0512C-ALUR, can provide more power efficiency for automotive applications. These are not limited to use in the powertrain, as they can also be used for applications such as car audio and door control modules.
However, all devices in a vehicle have to work together as cars become more and more connected. Therefore, it is important that they can interface with the vehicle networks. Freescale Semiconductor offers the MPC5566MVR132 in its MPC5xx range of microcontrollers that will work with the company’s MFR4310 FlexRay controller.
ECU diagnostics
There are a number of different tools available for use with the STMicroelectronics SPC56x range of microcontrollers for ECU diagnostics, specifically the SPC563Mx and SPC564Ax powertrain devices. Knowing when the Flash is protected and how to read the traceability information that is stored inside SPC56x Flash will allow carmakers to define and implement the right strategy for their ECUs. As IP protection and engine tuning are important, there is a need to identify configurations that do not require access to the Flash password.
When an ECU is suspected of incorrect behavior, it needs to run ECU-level diagnostics. ECU-level diagnostics in the field have two main goals. The first is to collect traceability information of the ECU configuration, and the second is to run ECU-level self-tests. An additional difficulty for ECU-level diagnostics is access to the PCB, as this is often hidden inside the ECU housing. As a result, several methods exist for ECU-level diagnostics with housing and PCB level diagnostics without housing.
ECU-level traceability involves hardware and software configuration information. On the hardware side, there is revision number and traceability information of the key components of the ECU. Software information includes the revision number of each top-level software component. In addition to this, date code of hardware or software components is also sometimes collected.
Figure 1: Top-level block diagram of the SPC563M64.
Each SPC56x has traceability information stored inside the Flash in memory locations, accessible by the application so that user software can be used to read them and send them over the selected diagnostic communications interface, whether that be UART, LIN, CAN or FlexRay. To send the traceability information, users can employ a user-defined diagnostic mode that is entered by the application software or use a serial boot mode. This is mainly driven by the password strategy of the carmaker.
When the Flash is protected, the application software can always read the traceability information. The application software may then have a specific diagnostic mode that lets it send this information over a predefined communications interface such as CAN, LIN, K-Line and FlexRay. This operation does not require engineers to know the Flash password to perform these operations in the field. However, using a serial boot mode, the engineers need the password. An external tool using the password can read the traceability information inside the device. That said, it is possible to use a serial boot mode using the serial links only, in which case the password is not needed.
To do this, the engineer needs to first reserve locations in the RAM, preferably with the highest addresses. The application software can then be used to systematically make a copy of the locations in the Flash to selected locations in the RAM during the power-on procedure. The ECU should be started in application mode first and then a reset applied without supply shutdown to ensure the MCU is brought up in serial boot mode. The software uploaded in RAM can then be used to export the traceability information using the selected serial link.
ECU level self-tests can be run either from the application software or from the microcontroller RAM. Even when high protection level is enabled, the SPC563Mx and SPC564Ax allow the uploading of software in RAM, which can be run without having to distribute any private password to users. This allows them to execute MCU-specific, ASSP, and power-stage self-tests.
When the SPC563Mx or SPC564Ax is put in serial bootstrap mode with serial boot control word different from 0x55AA, the Flash of the device is disabled and the JTAG port is enabled. To read the traceability information, the engineer must first reserve locations in the RAM. As before, the application software can be used to systematically make a copy of the locations in the Flash to selected locations in the RAM during the power-on procedure. The ECU should first be started in application mode and a reset then applied without supply shutdown. The tool can then be used with JTAG to connect to the device, load and execute software out of RAM.
The PCB of the ECU should be prepared for JTAG connection. In most cases, JTAG test pads can be placed close to the MCU for PCB testing. A good alternative is to have a provision for an SMD JTAG connector as it can be used for ECU testing and for PCB-level diagnostics.
Working together
One important aspect of the different devices in a vehicle is how well these can work together and with the vehicle networks. Freescale Semiconductor has the MPC5566MVR132-ND and others in its 16- and 32-bit MPC5xx range of microcontrollers, and these will work with the company’s MFR4310 FlexRay controller. The hardware interface between the two is straightforward, but software is also needed. By applying the techniques, users can quickly design a full-function FlexRay node.
The MPC5xx interfaces with the MFR4310 via an external bus interface (EBI). On the MPC5xx, the EBI provides individual address, data and control signals. The MFR4310 must be connected to the MPC5xx using the MFR4310 MPC mode.
Figure 2: Connecting the MFR4310 to an MPC5xx MCU.
The interface mode required for operating the controller host interface (CHI) is the MPC interface. There is one CHI and host interface clock for MPC mode – CHICLK_CC. This is the selectable external CHI clock input. The minimum external clock frequency for CHICLK_CC when selected is 20 MHz and the maximum is 76 MHz.
On the MFR4310, D0 is the least significant bit (LSB) of the data bus, and A1 is the LSB of the address bus, but on the MPC5xx, ADDR0 is the most significant bit of the address. Therefore, the data and address pins must be connected in reverse order to the MFR4310, that is, with D0 on the MFR4310 connected to DATA15 on the MPC5xx, and A1 on the MFR4310 connected to ADDR30 on the MPC5xx. The MFR4310 has a 16-bit data bus, but 8-bit data access is possible via the BSEL0# and BSEL1# signals. The MFR4310 must be configured for 3.3 V I/O (by powering VDDR with 3.3 V) to allow correct interfacing to the MPC5xx, whose EBI pins must also be powered from 3.3 V.
The software setup is concerned mainly with initializing the MPC5xx to allow successful communications with the MFR4310 controller host interface. When both devices have been initialized, the MPC5xx can read from and write to the MFR4310 registers.
The MPC5xx memory controller must be initialized for the EBI to use the correct chip select and the correct number of wait states, which depends on the internal bus frequency. After this sequence, the FlexRay block is configured as a FlexRay node and is ready to be integrated into the FlexRay cluster. The second step in the initialization sequence is to configure the chip select on the MPC5xx. The memory controller controls the chip-select generation for the MPC5xx. There are four chip selects on the MPC5xx, any one of which can be chosen as the chip select for the MFR4310. CS0# is the global chip select, which is used primarily for booting from external Flash memory. If it is used for this primary purpose, it cannot be used for MFR4310 communications, and a different chip select must be used. The option registers OR[0:3] and the base registers BR[0:3] are used to configure the chip select.
A number of wait states are required for successful read/write accesses between the MPC5xx and the MFR4310. This number should be set in the memory controller option register, bits SCY. BSEL0# and BSEL1# must be connected to WE/BE0# and WE/BE1#, respectively, via the MPC interface. This will allow 8- and 16-bit accesses.
This means the MFR4310 FlexRay controller can be successfully connected to the MPC5xx family of MCUs, with the correct number of wait states set in the MPC5xx option register for the appropriate chip select. The MPC5xx interfaces directly to the MFR4310 controller via the external bus and no glue logic is required. Software configuration is also straightforward, the peripheral being simply memory-mapped into the global address space. The results observed verify the optimal timing parameters required for successful communications between the host microcontroller and the stand-alone FlexRay communications controller.
Other microcontrollers
Many other microcontrollers can be used in this type of automotive application. For example, Atmel’s AVR low-power 32-bit microcontrollers, such as the AT32UC3C0512C-ALUR, can provide increased power efficiency for automotive applications, thanks to their higher processing power and accuracy. These allow implementation of features such as advanced control algorithms, voice control, and capacitive touch sensing. The UC3C 32-bit microcontroller also includes a peripheral event system, precision clocking, and high-performance peripherals. Integrated features include secure Flash memory, hardware-based safety mechanisms, the ability to interface directly with analog sensors, and a configurable software framework.
Figure 3: The UC3C 32-bit microcontroller in a car audio application (top) and a door control module (bottom).
Many automotive designs have a fragmented functional architecture; there is a separate chip for USB, one for CAN, another for graphics, one for each audio decoder supported, and so on. A microcontroller such as the UC3C, with peripheral integration and extended processing capacity, allows an entire system architecture to be consolidated onto a single chip for a car audio application. When used in a door control module, it can include the functions for mirror positioning, window-lifter operation, LED backlighting with a dimming function for the indicators, and interfaces for different types of sensors and switches to control the window lifter and the mirror positioning. The interconnection to the vehicle network can be implemented through a LIN or CAN interface.
The integrated floating point unit (FPU) simplifies application development. The implementation of complex algorithms in particular requires less effort and the wider dynamic range maintains high precision. Implementing complex algorithms using 32-bit floating-point instructions not only increases system accuracy and efficiency, but can accelerate development as well. Many applications can benefit from the use of an FPU, including these door control and audio applications.
Fuel pump
Infineon has a range of 8-, 16-, and 32-bit automotive-certified microcontrollers, which includes the 8-bit SAA-XC866-4FRA 5V BE. This uses an XC800 core and is compatible with standard 8051 processors. It uses a two-clocks-per-machine cycle architecture for memory access with wait state. On-chip memory comprises 8 kbyte of boot ROM, 256 byte of RAM, 512 byte of XRAM, 4, 8 or 16 kbyte of Flash or 8 or 16 kbyte of ROM with an additional 4 kbyte of Flash.
The high-temperature (up to +140˚C) operation of these devices makes them highly suitable for automotive applications such as engine close cooling fans, throttle controls, turbo chargers, water pump, oil pump, and lighting.
Figure 4: Infineon XC8xx 8-bit microcontroller in a fuel-pump application.
Figure 4 shows such a microcontroller in a fuel-pump application. This circuit also uses the BTN89xx, part of the Novalithic high-current PN half-bridge family, and the TLEA46xx low-dropout fixed-voltage regulator. This circuit can be tailored to performance and budget needs by using different products in the XC8xx family. The benefits of the circuit include fuel savings of more than 1%, for example, from 160 g to 158.4 g CO2/km. Hydrocarbon emissions are also reduced and the lifetime is increased. The company has also reported fuel efficiency increases of around 0.34 mpg.
Conclusion
The market for microcontrollers in automotive applications is growing rapidly. Each generation of vehicle relies more on electronics and the accompanying software. For example, the original Apollo guidance computer had just 2000 lines of code compared with ten million lines of code in an average car, and this is expected to increase by another order of magnitude over the next decade. As well as reducing fuel consumption, these microcontrollers are making cars more comfortable, increasing their safety, and helping entertain and inform the driver and passengers. The above applications are just a small sample of the way microcontrollers are providing local intelligence and control in modern vehicles.
