cembeddedstm32can-bus

CAN Error Counter TEC ( Transmitt Error Counter) Does Not Count Up In Error Passive State

I am trying to set up a bus-off condition to observe the behavior of the CAN peripheral. I am using an STM32F103 microcontroller, and I am attempting the following scenarios:

  1. Short-circuiting the CAN H to CAN L.
  2. Opening the CAN bus and attempting to transmit.
  3. Connecting CAN L to ground.
  4. Specifying the CAN Baud rate to an incorrect value and attempting to communicate over the network.

In all the scenarios mentioned above, a single scenario is consistently occurring: The TEC (Transmit Error Counter) counts up to 128 (0x80) and then switches to the Error Passive state (EPVF set to 1). However, the TEC remains unchanged, despite the fact that I constantly receive error conditions (via an Interrupt) with types such as ACK Error (LEC Register ID 0x03), Form Error (LEC Register ID 0x02), or even Stuff Error (LEC Register ID 0x10). These errors do not affect the TEC value, and it does not count up as I expected.

So my questions are:

  1. What is happening in the Error Passive state to the TEC that causes its value not to change, despite the presence of various types of errors?
  2. Are there any exceptions that prevent the TEC from counting up in the Error Passive state?
  3. Is there any specific condition or configuration I should consider to force the TEC to count up during the Error Passive state?

Here is my debuggin session:

enter image description here

Here is my CAN Configuration image: enter image description here

Note: I have tried to Disable Automatic Bus-Off Managment but the result is still the same.

CAN Error State Diagram: enter image description here

For more information on CAN Error Management: https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial

Solution

  • After hours of searching, I finally came across an article containing an interesting line:

    When a transmitter sends an Error Flag, the TEC is increased by 8. Exception 1: If the transmitter is Error Passive and detects an ACK Error because of the not detecting a dominant ACK and does not detect a dominant bit while sending its Passive Error Flag. Exception 2: If the transmitter sends an Error the Flag because a Stuff Error occurred during arbitration, and should have been recessive, and has been sent as recessive but monitored as dominant.

    As I mentioned, I've been able to encounter different types of errors, such as Stuff and Bit errors, but I haven't been able to observe a Bus-Off state. This is because I didn't enable the BOFIE (Bus-Off Interrupt Enable) bit in the CAN_IER (CAN Interrupt Enable Register). Furthermore, with Automatic Bus-Off recovery enabled, the Bus-Off state occurred briefly, making it imperceptible during a debugging session.

    Here's what I've done to reproduce the Bus-Off state:

    1. Set BOFIE to "1".
    2. Adjust the CAN prescaler to an incorrect value.
    3. Disable automatic bus-off recovery.

    Consequently, the Bus-Off state occurred after approximately 20 seconds of activating and deactivating CANoe. This allowed me to generate more errors with error codes 0x2 and 0x1.