Bidirectional I/O for communicating power mode between ECUs

In recent days, the number of electronic control units (ECUs) in the car continues to increase, at the same time there is a necessity to reduce the sleep current to improve the efficiency of the battery. In gas powered cars this has become mandatory.

Wow the engineering world with your unique design: Design Ideas Submission Guide

Limitations on controlling sleep state current

Nowadays, multiple ECUs are combined and powered from a single fuse/E-fuse to save on design costs, but this has the drawback of controlling the ECUs independently. If we want independent ON/OFF control, then the design cost will increase significantly.

To overcome the cost issue, each ECU comes with an additional I/O called “IGNITION” from the main ECU. Upon receiving the IGNITION input, the slave ECUs will wake up from the sleep state. This traditional architecture has its own limitations, for instance, it needs an additional communication interface like LIN, CAN, or Ethernet to communicate power modes such as sleep, active, and other status information. This increases the system cost further.

IGNITION is a unidirectional signal that will be asserted by the main ECU, for the slave ECU, this will be only an input. In order to detect this IGNITION input, the microcontroller in the slave ECU must be wake up source enabled. Even though the ECU is in a low power state, it consumes some power to keep the microcontroller in sleep state as well the DC-DC controller.

In many vehicle architectures the CAN or LIN interface is used for both communication as well as for Wake purposes (wake over CAN) where there is no need for an Ignition input. However, this consumes more sleep power than the previous condition.

Figure 1 The traditional vehicle architecture where multiple ECUs are combined and powered from a single fuse to save on design costs. This causes limitations on controlling current in the sleep state.

Proposed Solution

In the proposed architecture, the IGNITION I/O will be replaced with Hardware Wake I/O (HW_WAKE). A basic block diagram of the proposed architecture with Hardware Wake I/O is shown in Figure 2.

Figure 2 The proposed architecture using Hardware Wake I/O (HW_WAKE).

The internal circuit of a Hardware Wake I/O is shown in Figure 3.

Figure 3 The Hardware Wake bi-directional circuit with two transistors for controlling the output, a resistor divider for reading the same I/O, and diodes for reverse protection.

It consists of two transistors Q1 dual package (one NPN & one PNP) for controlling the output functionality as well as a simple resistor divider (R2, R3 & R4) for receiving or reading the same I/O. In addition, there are diodes (D1, D2) for reverse protection.

This is a bidirectional I/O, where we can receive signals like wake, reset, and sleep as well as send signals such as feedback and error status. The voltage levels of HW_WAKE I/O follow the battery voltage, with a controlled current of 13.5 mA in the proposed design. The user can decide their current by changing the resistor R1.

This circuit has short circuit protection and doesn’t require any fancy or protocol transceiver. The HW_WAKE signal can be connected “n” number of ECUs. In order to avoid I/O contamination, the user can read the “HW_WAKE_RX_TO_MCU” I/O status before asserting “HW_WAKE_TX_FROM_MCU_GPIO”.

Advantages of the HW_WAKE signal

Since this HW_WAKE is a bidirectional I/O, any ECU can act as a master, this is useful in instances where multiple wake sources are needed (e.g., if one ECU wakes and sends wake signals to all the others). The default state of the HW_WAKE I/O is open (0 V), it will be asserted (VBAT) only when required. Both control and status information are transmitted over this single wire interface by sampling, sending the timing-based signals.

While using HW_WAKE I/O, we can avoid using the LIN or CAN protocol medium, which saves lot of design and implementation cost. The user can implement their own timings for all the signals. We can completely power down the ECU during a sleep state, this way we can achieve an ultra-low power of almost 0 mA. This can be achieved by also connecting the “HW_WAKE_RX_TO_MCU” to the enable pin of DC-DC converter, enabling the power supply. This will also enable the microcontroller, once microcontroller is up, then it will hold the enable for DC-DC converter.

When a sleep/power down signal is received, the microcontroller will disable the enable for the power supply. This turns off the supply completely (like self-killing) achieving ultra-low (0 mA) power dissipation.

Timing examples

Control and status information and timing examples can be seen in Figure 4.

Figure 4 Control and status timing examples for WAKE_IN, ACK, ERROR, and POWER DOWN/SLEEP.

WAKE_IN: This signal is triggered by the main ECU by simply asserting the HW_WAKE. All other ECUs will wake up based on this signal. The typical high time of the signal is 100 ms (low time N/A).
ACK: The slave ECUs send an acknowledgement signal back to the master by simply asserting the HW_WAKE. Typical high time of the signal is 20 ms (low time N/A).
ERROR: Slave ECUs send a pattern signal high-low-high-low-high, to communicate the error status. The typical high time of the signal is 20 ms while typical low time is 10 ms.
POWER DOWN/SLEEP: The power down or sleep signal will be communicated from the master to all slave ECUs by asserting the HW_WAKE for 200 ms.

Rajesh Subramanyam (Senior Member, IEEE) received his bachelor’s degree in electrical and electronics engineering from Anna University, Chennai, India. He currently works as a senior hardware design engineer at an EV company in California, USA with a core expertise in automotive infotainment controller hardware design. Rajesh is also a member of the editorial review board for the SAE international journal.

Selvakumar Sonai (Senior Member, IEEE) received his master’s degree in microelectronics from BITS Pilani, India. He currently works as a senior hardware design engineer at an EV company in California, USA with a core expertise in automotive infotainment controller hardware design. Sonai is a member of IEEE Transactions on Circuits and Systems as well as the editorial review board for the SAE internal journal.

Logesh Sekar (Senior Member, IEEE) received his bachelor’s degree in electrical and electronics engineering from Anna University, Chennai, India He currently works as a senior hardware design engineer at an EV company in California, USA with a core expertise in automotive infotainment controller hardware design. Sekar is also a member of the editorial review board for the SAE international journal.

<!–
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>

The post Bidirectional I/O for communicating power mode between ECUs appeared first on EDN.

Bidirectional I/O for communicating power mode between ECUs

Become a member

Become a subscriber

Become a sponsor