The CAN status variables are all explained in can.h:

// CAN status
typedef struct
{
uint32_t interrupts;              // interrupts
uint32_t packets_rx;              // frames reveiced
uint32_t packets_tx;              // frames sent successfully
uint32_t txbuf_delay;             // frames routed through TX queue
uint16_t rxbuf_overflow;          // frames lost due to RX buffers full
uint16_t txbuf_overflow;          // TX queue overflows
uint32_t tx_fails;                // TX failures/aborts
uint32_t error_flags;             // driver specific bitset
uint16_t errors_rx;               // RX error counter
uint16_t errors_tx;               // TX error counter
uint16_t invalid_rx;              // RX invalid frame counter
uint16_t watchdog_resets;         // Watchdog reset counter
uint16_t error_resets;            // Error resolving reset counter
uint32_t error_time;              // monotonictime of last error state detection
} CAN_status_t;

The driver specific error flags need to be decoded in the context of the transceiver type: can1 = esp32can driver, losely SJA1000 compatible, can2 & can3 = mcp2515 driver.

esp32can:
    error_flags = error_irqs << 16 | (status & 0b11001110) << 8 | (ecc & 0xff);

esp32can error & status bits are documented in "esp32can_regdef.h", see SJA1000 documentation for more details.

mcp2515:
    error_flags = (intstat << 24) | (errflag << 16) | intflag;

mcp2515 interrupt & error bits are documtented in "mcp2515_regdef.h", see MCP2515 documentation for more details, plus some synthetic internal debugging flags as ORed in by the driver in `mcp2515::AsynchronousInterruptHandler()` beginning on line 500.

Interestingly both of us saw can2 errors in pairs: one with errflags=0x23401c01 and one with 0x22401c02. In my case these were either 0 or 10 ms apart.

intstat 0x23 = 0b00100011 = Error state change (details in EFLG) | RX buffer 1 full | RX buffer 0 full

… 0x22 = same, but only RX buffer 1 full (RXB0 has just been cleared by the driver)

errflag 0x40 = 0x01000000 = Receive Buffer 0 Overflow
intflag 0x1c01 = all indications detected & processed at RX buffer 0

… 0x1c02 = same, but at RX buffer 1

So these are simply indications of RX buffer 0 overflows. These are no "real" overflows, as RX buffer 1 was still available, so the frames were not lost and the rxbuf_overflow counter was not incremented.

The driver could clear this condition to avoid signaling this as a CAN error. I think we kept it that way because an RXB0 overflow already indicates a lot of traffic on the bus. This could also result in a warning log, but the CAN framework doesn't know how to distinguish driver specific errors from warnings.

Err flags: 0x01000001

…simply means RXB0 has been received & read.

Regards,
Michael

Am 23.01.25 um 14:48 schrieb Chris Box via OvmsDev:

On 2025-01-23 12:11, Developer From Jokela via OvmsDev wrote:

E (445282) can: can2: intr=240803 rxpkt=242887 txpkt=6 errflags=0x22401c02 rxerr=0 txerr=0 rxinval=0 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0

Ok, now putting Developer From Jokela's post together with Michael's I think I understand what this is telling us.

First, E means error.

The presence of this line in the log means there has been an error on can bus 2. The values given appear to be the current values of some counters.

The code is in can/src/can.cpp. This has basic deduplication by summing most of the counters and errflags, and only logging if this changes. Interestingly both of us saw can2 errors in pairs: one with errflags=0x23401c01 and one with 0x22401c02. In my case these were either 0 or 10 ms apart.

The flags appear to derive from mcp2515/src/mcp2515.cpp but it's not clear to me what they mean.

OVMS# can can2 status

CAN: can2

Mode: Active

Speed: 500000

DBC: none

Interrupts: 291197

Rx pkt: 293642

Rx ovrflw: 0

Tx pkt: 6

Tx delays: 0

Tx ovrflw: 0

Tx fails: 0

Err flags: 0x01000001

Rx err: 0

Tx err: 0

Rx invalid: 0

Wdg Resets: 0

Wdg Timer: 9 sec(s)

Err Resets: 0

Question: If the log tells us that can2 errors have occurred, why does "can can2 status" report zero values for errors?

Chris
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926