FlexCAN Wakeup Triggered When CAN Receiver Is Not Connected

[Jamal]

Hi NXP Team,

We are using FlexCAN1 as a wakeup source on our custom board.

Our setup consists of a CAN sender and a CAN receiver. The sender continuously transmits CAN messages, while the receiver may not always be connected to the CAN bus.

We have observed the following behavior:

CAN1 is configured as a wakeup source.
The device is put into sleep mode.
The CAN receiver is disconnected from the bus.
The CAN sender continues transmitting CAN frames continuously.
The device unexpectedly wakes up from sleep.
When we check the wakeup source, it indicates that CAN1 triggered the wakeup.

Our expectation is that when no receiver is connected to the CAN bus, the transmitted CAN frames should not wake the device. The customer intends to use CAN as a wakeup source, but the CAN sender may continue transmitting messages even when no other node is present on the bus. In this scenario, the device should ideally remain in sleep mode until a valid CAN wakeup event occurs.

Could you please clarify why CAN1 is triggering the wakeup in this condition? Is this expected FlexCAN behavior? Are there any recommended configurations, filters, or low-power modes that can prevent unintended wakeups while still allowing CAN to be used as a valid wakeup source?

Any guidance or suggestions would be greatly appreciated.

Regards,
Jamal Deen

[kef2]

Clearly CAN bus terminator is disconnected as well and CAN ends are floating. If you can't move terminator to unconnectable side, then try connecting something like >1k resistor between CANL and CANH, so that open ends won't float. 

[yipingwang]

On NXP i.MX platforms, standard FlexCAN wakeup is generally bus-activity based. The FlexCAN self-wakeup logic monitors the CAN bus for wake-triggering transitions while the controller is in low-power/stop mode; it is not described as requiring another node to be present or ACK the frame before wake occurs. Therefore, if another CAN node continues transmitting, the electrical activity on the bus can wake the sleeping device even when the intended receiver is not actively participating on the bus. 

If the application requires wakeup only for specific CAN frames, then standard FlexCAN self-wakeup is typically not sufficient by itself. A selective wake mechanism should be used instead — for example, FlexCAN pretended networking (if supported on the target device/software stack) or a selective-wakeup CAN transceiver such as one supporting partial networking.

Recommended ways to avoid unintended wakeups

1) Use selective wake / pretended networking if your exact SoC and software stack support it

2) Use a selective-wakeup CAN transceiver (partial networking)

3) If the sender free-runs continuously, don’t rely on generic “bus activity” wake