How are MCUs in automotive ECUs woken up from low-power mode? - Page 1
Forum section: electronics / general

author: Halide
author_rank: Contributor
timestamp: August 25, 2025, 02:55:34 pm
content: Hi everyone!Some time ago, I tried to sniff CAN bus communication in a car.I noticed that after a while, all traffic stops — which I assume is normal, since the ECUs go into sleep mode.But when I send a dummy message with a random address, all communication starts again.So here’s my question: does anyone know how automotive engineers usually handle low-power modes with waking up the MCU on CAN activity?From my experience with MCUs (and only very basic knowledge of the CAN bus), I guess they might connect the RX pin from the transceiver to an MCU pin and wake it up on an external interrupt.Or is there a better way to do it? Maybe some specialized circuits for this?I’m not trying to build anything specific, just trying to understand how low-power modes and wake-on-CAN-bus activity work in modern cars.Thanks!

author: hans
author_rank: Super Contributor
timestamp: August 25, 2025, 03:43:50 pm
content: My first question that pops into mind is.. are the MCUs actually put in their low power mode, or does the bus enter a low power mode? CAN is not a low power protocol at all: it has 120 Ohm termination resistors, and the dominant CAN state consumes close to 100mA at 5V (0.5 Watt). So stopping the communication does make sense from that perspective.But also, a MCU low power standby (or similar) is in the order of uAs. Probably all the regulators and CAN transceivers consume a lot more power. So its relatively insignificant for the MCU to turn off all its clocks and wakeup from a pin interrupt (and potentially missing the CAN frame). Perhaps its just idling at a few MHz while consuming a couple of mA to listen for CAN frames is fine. I'm unaware of any MCU that can actually wake from standby whilst CAN is actively running. Most CAN systems will require tens to hundreds of PPM timing accuracy.I'm fairly certain many cars will cut power to bus nodes, for example, depending on the ignition key. A car battery shouldn't run flat with a few mA even for months. But its very subjective which car, not all are made equal. So in which conditions are you seeing this phenomena that communication on the CAN bus goes silent and resumes?

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 25, 2025, 03:50:59 pm
content: First thing, you don't really know if said MCU (which may also be a full "SoC" rather than simple MCU) goes into a "low-power mode". Could also be that they have "task" that handles OBD communication, that gets disabled automatically after a given timeout, for safety reasons.Now regarding your specific question, many modern MCUs have a bunch of wake-up sources that can be configured, so it's often just a matter of configuring CAN activity (or UART, or....) as a wake-up source. No need (usually) to hack it, "modern" MCUs can be woken up from many sources other than just GPIO level.

author: langwadt
author_rank: Super Contributor
timestamp: August 25, 2025, 04:07:48 pm
content: MCU in low power standby (uA) with a wakeup pin connected (via large resistor?) to CANH or CANL?

author: langwadt
author_rank: Super Contributor
timestamp: August 25, 2025, 04:14:42 pm
content: Quote from: SiliconWizard on August 25, 2025, 03:50:59 pmbut transceivers etc. quickly adds up, there a huge number of devices in modern cars. The whole might use something like 10-20mA when off, I think the target for an ECU is <100uA

author: Benta
author_rank: Super Contributor
timestamp: August 25, 2025, 05:01:46 pm
content: Typical "all systems off" current in a modern car is 20...50 mA. Plenty to keep the MCUs running.

author: free_electron
author_rank: Super Contributor
timestamp: August 25, 2025, 06:09:19 pm
content: the CAN controllers have a "wake on can" function. CAN activity kicks the processor out of sleep.Like "wake on lan"

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 25, 2025, 07:25:05 pm
content: Quote from: langwadt on August 25, 2025, 04:14:42 pmYes, but I mentioned that first, because we don't know anything about the OP's particular use condition and vehicle. So, we don't know.But if the question is more a general question about how to handle low-power modes with CAN, there are two parts to that: the MCU/SoC part, as I mentioned, which usually can be woken up from CAN activity (and a number of other sources) and the CAN transceivers (which I didn't mention), which are usually external (I don't remember of a single MCU with integrated CAN transceivers, but that may exist). Many "modern" CAN transceivers implement low-power modes, so they can basically go to some low-power mode on their own after some bus inactivity, and then often there's a pin to trigger a deeper low-power mode yet, that a MCU/... can control to put the transceiver in ultra-low power mode, and then go into a low-power mode itself. Those transceivers will get out of this deep low-power mode on their own when they detect bus activity, then some activity will appear on the RX/TX lines on the MCU side, which can in turn wake it up, as I said.So, I suppose that the main underlying question was about monitoring the CAN bus itself, and the answer is that many transceivers implement that, so you don't have to.

author: tom66
author_rank: Super Contributor
timestamp: August 25, 2025, 08:46:44 pm
content: I have seen one make of car where the CANH line gets a pulse on it which causes the gateway to wake up. Normally both lines go to hi-z on all modules and the 120 ohm resistors plus the 100k or so pulldown on each CANH/L RX pin keeps the bus in a stable state.In a modern car usually the gateway is powered up in sleep, but most if not all other modules that are not required for wakeup like remote keyless entry will be on a 12V supply that is isolated when the vehicle is asleep.I'm also aware of at least one case of an EMC test where a truck manufacturer discovered a rather unfortunate bug in a certain German-made ECU, where an external ESD event would wake up the entire vehicle bus (which would cause the relevant 12V supplies to come online too), and due to an incomplete software state, would remain in this powered up state until the 12V battery ran flat. This would mean that someone could brush past the truck, trigger the ESD event on the CAN bus, and then drain the vehicle battery after about 30 minutes. Last I heard is it still wasn't fixed since the end equipment manufacturer considered it someone else's problem... vehicle architecture is just a nightmare given all the players involved.

author: Halide
author_rank: Contributor
timestamp: August 25, 2025, 10:31:15 pm
content: Wow guys, a lot of knowledge thank you!Quote from: tom66 on August 25, 2025, 08:46:44 pmHmm, so if I understood you correctly, most of the ECUs are hardly ever disconnected from the supply line by some kind of ‘master’ ECU?Quote from: SiliconWizard on August 25, 2025, 07:25:05 pmI did not specify what car we’re talking about, because as I said, I don’t want to make any modifications there — it’s just engineering curiosity.But regarding the rest of your response: I looked into the STM32H7 reference manual and couldn’t find any information about waking it up on CAN bus activity. So I assumed that automotive applications use some specialized MCUs?Before responding to those messages, I did some research (though not very deep, since I lack the knowledge needed to fully understand the issue I’m asking about).I found that Infineon has some specialized MCUs for automotive ECUs, but the datasheets are hidden (apparently you need special access to download them).As for CAN transceivers: some time ago I used a very simple TJA1050 in a basic application, just to try establishing communication between two STM32s. I don’t remember anything about low-power modes there. So I started digging into this, and found that there are some specialized CAN transceivers which can recognize special frames — wake-up patterns.Is that what you were talking about? That when they detect bus activity, they exit from low-power modes? Or is it something else?Quote from: SiliconWizard on August 25, 2025, 03:50:59 pmOh, maybe I need to be a little more precise here. I’m not monitoring CAN activity on the OBD bus. I’m connected to the CAN bus inside the car - had a scope and CAN transceiver connected to the bus.I know that MCUs can be woken up from many sources, but as I mentioned earlier, I can’t find any information for the STM32H7 (I know it’s quite an old MCU, but it’s the one I have the most experience with, so I chose it as the starting point for my research) that would allow waking it up directly from CAN bus activity. So I assumed they just use some EXTI pin and connect the CAN RX pin (from the transceiver) to it (maybe I’m misunderstanding that diagram).https://en.wikipedia.org/wiki/CAN_bus#/media/File:CAN-bus-frame-with-stuff-bit-and-correct-CRC.pngBut as I said, I don’t know much about the MCUs used in automotive, so I supposed they might have some feature that allows the MCU to wake up from CAN bus activity?Quote from: hans on August 25, 2025, 03:43:50 pmHmm, maybe a strange question, but does changing the MCU’s frequency (I know PC processors do it all the time, but in my mind they’re much more complex devices) cause any risk of losing data on the CAN bus? I mean, it takes a bit of time to lock PLLs and run all the procedures that switch clock sources while speeding up. Or is there a nice, quick way to do this that I just don’t know about?Sorry for my newbie questions, but until now in my professional career I’ve worked only with battery-powered devices. So when I try to understand how such a huge system like a car manages energy, a lot of questions come up.

author: Benta
author_rank: Super Contributor
timestamp: August 25, 2025, 11:42:29 pm
content: If you're monitoring from inside the car, you're doing it wrong.As soon as you open the door, all kinds of systems come alive.As an experiment:place a current monitor on the battery. Close and lock the the car . It will take some minutes before current draw drops to the normal ~30 mA.Now open a door or the trunk and see what happens.And no, it's not just the interior lighting (turn it off on the switches before the test).

author: langwadt
author_rank: Super Contributor
timestamp: August 25, 2025, 11:46:35 pm
content: Quote from: Benta on August 25, 2025, 11:42:29 pmit can be bypassedhttps://youtu.be/Ik9MK67Z76M?si=tBJM8MkQsdaRMGSE&t=914

author: neillnz
author_rank: Contributor
timestamp: August 26, 2025, 02:40:18 am
content: I have been mucking about with this lately. CAN transceivers typically have three power modes typically called "off", "silent" and "normal". In silent mode the transceiver listens only and the Tx drivers are disabled which saves a lot of power, and of course normal mode where the Tx drivers are enabled. In Silent mode you could expect a typical current consumption of perhaps 2.5 mA, which is still significant if you have say 10 transceivers.Then there are transceivers with a 4th mode which also disables the Rx buffers and the typical current consumption might be 10 uA. The ATA6560 has this mode. In this so called "standby" mode there is a low power comparator that will take the RxD line low upon bus activity. It does not automatically wake up in to silent or normal mode, that is the job of the MCU.I have been doing tests with the ATA6560 in silent mode. With my MCU in a low power mode in which the crystal osc is kept running it is able to see the high to low state on an external interrupt pin, wake up, and not miss the 500 kbps CAN frame that caused the wake up. I have been testing this by getting the MCU into a low power mode and then sending a burst of 20 CAN frames and seeing how many the MCU receives without error. It consistently never misses any, however if I use a low power mode where the xtal osc is turned off then I miss the first 8 frames as it takes a while for the xtal osc to be ready.Next I will be testing the performance of going from standby mode to silent / normal mode. I expect too consistently miss the first frame as the ATA6560 datasheet says it takes typically 47 uS to come out of standby mode which is around 1/4 of a 500 kpbs frame.As to how the automotive manufacturers implement a wake up scheme all I can say for certain and from experience is that they will all do it differently! So sorry, not much help there.

author: tom66
author_rank: Super Contributor
timestamp: August 26, 2025, 01:29:01 pm
content: Quote from: Halide on August 25, 2025, 10:31:15 pmDepends on the ECU. Power isolation is common though.I can speak most accurately to the VW system since I am familiar with their cars.- Keyless entry/remote unlock module is always powered- Telematics module is always powered (remote climate control, etc.)- Alarm module is always powered, and also has its own battery and (I think) own siren, so in case 12V power is cut it can still alarm- Body control module & gateway (combined on many cars) are usually always poweredMost other modules are asleep and have 12V power isolated when they are not in use.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 26, 2025, 02:48:10 pm
content: Quote from: Halide on August 25, 2025, 10:31:15 pmThe STM32H7 series is not that old. But yes, it doesn't have CAN as a wakeup source. It actually has limited wakeup sources compared to the low-power series (such as the STM32U5), which makes sense, as the lowest power modes are probably less critical in terms of market for "performance" MCUs. That said, yes, you can always use a pin that has wakeup capabilities and either route it externally to the CAN RX pin, or internally (via software and pin muxing) if one of the CAN RX pins happen to be shared with a wakeup pin - then it's just a matter of reconfiguring the pin function before going to a stop mode, and re-configuring it for CAN when it wakes up.And that's if you want to use one of the "stop" modes. If the "sleep" mode (which is not as low power, but still cuts power draw significantly especially on a Cortex-M7 with "high" clock frequencies) is sufficient, then you don't need a wakeup source but can get out of sleep by any interrupt, CAN included.As to transceivers monitoring the bus itself, neillnz gave you more details.

author: Halide
author_rank: Contributor
timestamp: August 26, 2025, 04:55:15 pm
content: Hi everyone!Quote from: Benta on August 25, 2025, 11:42:29 pmOh, one more thing I didn’t mention, sorry about that. I connected the cable to the CAN bus and did that test on a closed car. I supposed that opening the door could wake up the car.Quote from: neillnz on August 26, 2025, 02:40:18 amWow, thank you for sharing those experiment results! Out of curiosity, was it a 'regular' MCU, or did you use one designed for automotive applications?Once again, thank you all for sharing your knowledge!

author: hans
author_rank: Super Contributor
timestamp: August 26, 2025, 05:10:19 pm
content: I was interested to see if NXP supports this. They have a higher stake in supporting automotive applications. Here is some datasheet snippets for LPC1768:Quote0.63uA in deep power-down ("Shutdown" in STM32 land), 31uA in power-down and 240uA in deep-sleep. It takes around 100us for the processor to exit power-down mode, which for CAN bus is already an eternity.These specs are on-par or better than a STM32F10x from similar design era, but nowadays its unremarkable, and e.g. the F103 doesnt feature wake on CAN.However, for the LPC1768, the CAN and USB activity wakeup are separate interrupt vectors. It actually looks very much like tying the I/O to an external interrupt pin and waking on level change. In addition:QuoteThis suggests it will at least miss the first message, as the wake-up edge occurs and the controller then first needs to see free bus condition again. And it also does not say what time to incorporate for external oscillator startup.A 11-bit frame can be up to approx. 100 bits long, taking ~200us to send at 500kbps. Perhaps enough time for a RC oscillator wakeup (which e.g. MSP430 and STM32U5 uses for on-demand clocks), but an external crystal+PLL will take way longer. E.g. STM32F103 states a 2ms oscillator startup time for HSE crystal, plus 350us PLL lock time. A STM32U535 also 2ms, plus 40us PLL lock time (2% of target frequency, which is not great). A short scout at oscillators doesn't look that much better. Most vendors don't give a typical spec, only 10ms max..I don't think any MCU exists that can really be in a standby or power-down mode with all its oscillators off, and start doing coherent CAN stuff without a considerable amount of time passed.But, a dummy+10ms wait is still a decent wake-on-CAN feature.

author: neillnz
author_rank: Contributor
timestamp: August 26, 2025, 11:01:40 pm
content: Quote from: Halide on August 26, 2025, 04:55:15 pmI have been using an AVR, AT90CAN128, it's 8 bit, it's old but still in production and is automotive qualified . It has a complete CAN peripheral which uses it own registers so it does not require access to the RAM, it's super simple. There are of course more modern MCUs but this one does exactly what I need it to do for now. It draws 700 uA in "powerdown" mode @16 MHz which means the CAN is off, however the xtal osc is kept running and it takes just I think 4 cycles to wake up the CAN, so more or less instantaneous. There is no "wake on CAN" function, however I paralleled the CAN RxD line to one of the external interrupt pins.

author: globoy
author_rank: Frequent Contributor
timestamp: August 27, 2025, 02:46:45 pm
content: I have the electronics for an EV currently sitting in my lab. The main ECUs are powered from an always-on 12V connection and are always running code. For example, the Body Control Module (BCM) needs to run since it implements the alarm system, key fob communication (through an external always powered transceiver) and door lock management/RFID Key detection. The telecommunications unit is also always active as is the EV traction system controller and the Meter (instrument panel controller) since it is maintaining timers to initiates climate control functions and charging. The traction battery BMS is also always powered so it can perform balancing and manage things like pack heating when it is too cold. There are also some ancillary controllers that control various body- and power-related functions that are also always active so they can switch on power to other ECUs when commanded via CAN. All together this car can consume up to 100 mA while sleeping (it protects the 12V battery by occasionally powering up the HV system so the DC-DC can charge it). CAN messages from the main controllers inform other ECUs when they're allowed to communicate on the busses and they are the first and last to put messages on the busses (I think a jabbering ECU could keep the CAN busses alive indefinitely). As mentioned earlier, the car wakes up occasionally to manage some housekeeping. I hear a relay clicking once-in-a-while although the dashboard never lights up (but there is CAN bus traffic).

author: Dave
author_rank: Super Contributor
timestamp: August 27, 2025, 10:35:57 pm
content: Quote from: Halide on August 25, 2025, 02:55:34 pmThe task is usually done by a System Basis Chip (SBC). They come in many different flavors, but they usually serve as the transceiver for either CAN or LIN, wake the MCU on bus activity, perform the power conversion and supervise the power rails. Sometimes you will also find an external watchdog inside.The fancy ones can even be configured to only wake on specific CAN IDs.

author: Halide
author_rank: Contributor
timestamp: August 29, 2025, 05:21:43 pm
content: Hi everyone!Quote from: hans on August 26, 2025, 05:10:19 pmOh, nice — so there’s a kind of dedicated CAN controller in specialized MCUs that can operate in low-power mode. Thank you for that datasheet quote!Quote from: Dave on August 27, 2025, 10:35:57 pmOh, nice! I was able to find some short briefs about NXP SBCs (very irritating that they hide the datasheets...), and there they clearly state that I can implement wake on CAN.So this is exactly what I was thinking — automotive MCUs have more complex CAN interfaces than the H7 I mentioned at the beginning (which is quite obvious if you’re trying to sell a MCU for something that uses CAN buses).But I have one more question for you guys: I found that CAN provides something called a Wake-Up Patternhttps://support.vector.com/kb?id=kb_article_view&sysparm_article=KB0012123&sys_kb_id=ec35fd32878b3954cd36fd99cebb3509&spa=1but I do not fully understood how it work.Is this a feature that also needs to be supported by the MCU, or is it only handled by a specialized transceiver (like the TCAN1043A, for example)?

author: hans
author_rank: Super Contributor
timestamp: August 30, 2025, 09:26:21 am
content: @HalideThe CAN controller doesn't really operate.. its shutdown but there is some special wakeup logic that wakes the MCU with dominant bits on the bus. There is a fair amount of time needed to start up all oscillators for the precise timing necessary for reliable bus communications.The wake-up pattern you refer to is interesting, didn't know that. But this is not part of CAN, but rather the road-vehicle standards. I personally haven't worked with those, only ISOBUS or proprietary CAN standards for things like motor controllers.The wake-up feature on the LPC1768 doesn't look that sophisticated, e.g. something you could add externally with a level change interrupt on the CAN RX line. If you add some time hysteresis (e.g. 5us), then I'm fairly certain you can implement said wake-up pattern for any MCU.

author: Chicane
author_rank: Contributor
timestamp: September 01, 2025, 06:01:54 am
content: Automotive MCU's all have "Wake on CAN" , as someone already mentioned. The CAN transceivers used have that too. They also go in Sleep and wake up on the "wake up" part of the can message. The transceiver pulls low its RX for ... was it 3 cycles? to tell the MCU "wake up" was received. You can read that in pretty much all CAN transceiver datasheets from NXP, TI and ON Semi.Besides, vital modules like BCM and ECU have a separate Wakeup connection between them, as a redundancy feature. It's a wire that will probe similar to Ignition On in an old car. It's there to ensure a vital module doesn't go in Sleep while the engine is running, likely a crash safety feature.

author: Halide
author_rank: Contributor
timestamp: September 04, 2025, 07:18:41 pm
content: Quote from: hans on August 30, 2025, 09:26:21 amOh, I understand now. Thank you!Thank you all for your responses. Now I understand how it works much better!