S32K144 FlexCAN intermittent failure with temporary low resistance between CANH and CANL I am troubleshooting an intermittent CAN communication issue on an electric/autonomous vehicle VCU based on an **NXP S32K144**. The affected network is CAN3 and consists of: - S32K144-based VCU - Autonomous driving PC - Instrument cluster - MDPS The termination configuration is: - Autonomous driving PC: 120 ohms - Instrument cluster: 120 ohms - VCU CAN3: **no termination resistor** - MDPS: no termination resistor Therefore, the complete CAN3 network normally measures approximately **60 ohms between CANH and CANL**. ### Long-term intermittent symptom The vehicle can operate normally for approximately 2–3 hours, but occasionally CAN3 communication becomes unstable. Typical symptoms include: - Some CAN3 messages are no longer received - Gear commands may stop working - CANalyzer has shown Stuff Error, Bit Error, and Overload Error - Power cycling the VCU has often restored normal operation The VCU was previously replaced for an unrelated issue, but the same CAN3 communication problem occurred both before and after the VCU replacement. For this reason, I do not believe the issue is simply a failure of one specific VCU. ### Recent severe failure Recently, the vehicle appears to have been left with the ignition/power ON overnight. Because the autonomous PC cannot operate unless the vehicle/VCU power is ON, both the **VCU and autonomous PC were most likely powered for an extended period**, and the CAN3 network was active overnight. The next morning: 1. CAN3 communication was initially present. 2. However, Stuff Errors were also observed. 3. The autonomous PC was then power cycled. 4. After this, CAN3 communication completely stopped. After powering the vehicle OFF, I measured the resistance between CANH and CANL on the complete vehicle network. The measured resistance was approximately: **6 ohms** I then completely disconnected and removed the VCU from the vehicle. On the isolated, unpowered VCU, the CAN3 CANH-CANL resistance measured approximately: **7 ohms** Again, the VCU CAN3 channel has **no termination resistor installed**, so this low resistance cannot be explained by termination. ### Resistance changed while the VCU was unpowered The VCU was left completely disconnected and unpowered. Over several hours, the CANH-CANL resistance gradually increased: **~7 ohms → ~33 ohms → ~60–75 ohms** It eventually remained around **74–75 ohms** for some time. I then brought the VCU to the office and measured several components around the CAN3 physical-layer circuit with a digital multimeter. The circuit includes: - CAN transceiver - CAN protection/TVS device - Common-mode choke - Small capacitors connected to CANH/CANL - Unpopulated split termination resistors While measuring the pins of the CAN protection device and nearby CAN nodes, I measured approximately 53 kohms between the nodes connected to CANH and CANL. I then immediately re-measured CANH-CANL at the VCU connector. The resistance had suddenly changed from approximately **74 ohms to approximately 53 kohms**. No component was replaced or desoldered. ### Current condition The same VCU was then reinstalled in the vehicle. CAN3 communication is currently completely normal. - CAN3 is stable with the autonomous PC OFF - CAN3 is also stable with the autonomous PC ON - Messages transmitted by the autonomous PC are received normally - Power cycling the autonomous PC currently does not reproduce the failure - No Stuff Error is currently observed ### Questions regarding S32K144 / FlexCAN I would appreciate advice regarding the following: 1. Can S32K144 FlexCAN enter an Error Passive, Bus-Off, or other abnormal state that may persist until the VCU is fully power cycled? 2. Which FlexCAN registers and error counters should be monitored to determine whether the controller is entering Error Passive or Bus-Off? 3. Is there a FlexCAN configuration that can disable or affect automatic Bus-Off recovery? 4. What is the recommended method for implementing reliable Bus-Off detection and recovery on S32K144? 5. Could an abnormal FlexCAN state cause the external CAN transceiver to remain in an unusual operating state? I understand that **Bus-Off alone should not explain approximately 7 ohms between CANH and CANL on a completely isolated and unpowered VCU**. Therefore, I suspect there may be both: - A CAN controller/error-recovery issue, and/or - A CAN physical-layer/transceiver/protection-circuit issue One additional observation may also be relevant. In previous oscilloscope measurements, CANH-to-ground and CANL-to-ground waveforms became noticeably noisier when the autonomous PC was operating, while the CANH-CANL differential waveform remained relatively clean. The autonomous PC is connected to the vehicle CAN network using only CANH and CANL. A separate CAN ground wire is not connected. I would appreciate any recommendations on which FlexCAN registers, error flags, or diagnostic signals should be monitored if this failure occurs again. Thank you. Re: S32K144 FlexCAN intermittent failure with temporary low resistance between CANH and CANL Hello Julián, Thank you for the detailed explanation. Regarding your question, we have **not yet tried re-initializing only the FlexCAN module** when the long-term intermittent CAN failure occurs. Until now, when the CAN communication stopped, we recovered the system by power-cycling the entire VCU. Therefore, during the next occurrence, we will first check the FlexCAN status before resetting the VCU. We plan to monitor: - ESR1.FLTCONF - ESR1.BOFFINT - ECR.TXERRCNT - ECR.RXERRCNT - CTRL1.BOFFREC Then, if the module is in Bus-Off, we would like to test whether re-initializing only the FlexCAN peripheral restores communication. The CAN transceiver used in our VCU is a **Texas Instruments SN65HVDA540-Q1**, so it is a third-party transceiver. We also contacted TI regarding the abnormal physical-layer behavior. TI confirmed that approximately 7 ohms between CANH and CANL on the isolated and unpowered VCU is not a normal condition of the SN65HVDA540-Q1. They recommended investigating the external CAN physical layer, including the protection/TVS device, CAN-line capacitors, PCB leakage or contamination, common-mode choke, ground/common-mode conditions, and the transceiver. This is consistent with your comment that a FlexCAN software state cannot explain the CANH-CANL resistance change. I have attached the relevant CAN interface schematic. Please note that **R14 and R15 shown in the schematic are not populated on this CAN channel**. The actual two 120-ohm termination resistors are located at the autonomous driving PC and the instrument cluster. We will also investigate the ground/common-mode condition between the VCU and autonomous driving PC, as you recommended. Currently, the PC is connected to the CAN network using CANH and CANL only, without a separate CAN ground wire. One additional question: Could you please recommend the proper procedure or SDK/API sequence for **re-initializing only the FlexCAN peripheral on S32K144 after a Bus-Off condition, without resetting the entire MCU**? We would like to implement this as a diagnostic test so that, during the next failure, we can determine whether FlexCAN re-initialization alone restores communication. Thank you again for your support. Best regards, Han Re: S32K144 FlexCAN intermittent failure with temporary low resistance between CANH and CANL Hello @zeinmotors,
Q1. S32K1 devices, by default, have 'Bus-Off recovery' enabled through CTRL1[BOFFREC]:
Julin_AragnM_0-1787163619190.pngJulin_AragnM_0-1787163619190.png
It automatically tries to recover to normal state after entering the bus-off state: "Error Active-> Error Passive-> Bus Off-> Error Active.....". If disabled, you can re-initialize the CAN module to clear Bus Off sate, which is also done by power-cycling the VCU.
Have you tried re-initializing the CAN module instead of power-cycling the VCU to see if this fixes the original long-term intermittent symptoms?
Q2. You can monitor ESR1 and ECR registers, specifically FLTCONF will indicate error active, passive or bus off, BOFFINT is set when FlexCAN enters bus off and finally TXERRCNT & RXERRCNT are error counters which accumulate the counts of Tx and Rx errors respectively.
Q3. See Q1.
Q4. Bus Off detection is enabled by setting CTRL1[ERRMSK] & CTRL1 [BOFFMSK]. Inside your error callback/handler, read ESR1 and check for BOFFINT.
If FlexCAN is in Bus Off, and Bus Off Recovery is set to manual (CTRL1[BOFFREC] = 1), you must:
Monitor 128 occurrences of 11 consecutive recessive bits on the CAN bus.
Clear BOFF_REC.
Or, you can re-initialize the CAN module.
If automatic recovery is enabled (CTRL1[BOFFREC] = 0), Bus Off recovery will happen automatically, provided that the conditions for Bus Off are removed.
There is a simple S32K144 FlexCAN error ISR example: Example S32K144 FlexCAN TX/RX/Error ISR test S32DS2.2.
Q5. I am not aware of any situation where FlexCAN Bus Off forces transceiver to abnormal state. Can you also share which transceiver you are using? Is it an NXP device, or third party?
I agree with your statement that this points to both a SW Bus Off recovery handling issue, along with a physical layer issue, as a software state cannot explain the CANH CANL resistance change.
If possible, please share schematic for the CAN interface (you can enter a support case if you wish to avoid sharing it to public community: NXP Support). I suggest also looking over the S32K1's Hardware Design Guidelines document and refer to the CAN section for pointers.
Lastly, you can also implement the recommendations below:
When a common mode choke is used, it should be placed close to the transceiver bus pins CANH and CANL.
The PCB tracks for the bus signals CANH and CANL should be routed close together in a symmetrical way. Its length should not exceed 10cm.
Avoid routing other “off board” signal lines parallel to the CANH/CANL lines on the PCB due to potential “single ended” noise injection into CAN wires.
The ESD protection should be connected close to the ECU connector bus terminals.
The track length between communication controller / μC and transceiver should be as short as possible
The ground impedance between communication controller (μC) and transceiver should be as low as possible.
Avoid applying filter elements into the GND signal of the μC or the transceiver. GND has to be the same for Transceiver, the μC and the external bus system.
Best regards, Julián
查看全文
