Chris, those are normal stats for can1, and occasional stuck bus-off error logs are also normal, as those are a flaw in the ESP32 CAN hardware, or more specifically a workaround for the workaround for that hardware bug, as explained in the source (search for "TWAI_ERRATA_FIX_BUS_OFF_REC"). That's why you only see this log for can1, as the MCP2515 doesn't have that bug. The stuck bus-off mostly occurs when the module tries to transmit to an offline bus, so that matches it happening right after you turned the car off.
0x8048d9 was logged twice last night while parked and locked, with nothing going on
0x80 = IR.7 Bus Error Interrupt 0x48 = SR.6 Error Status (1=warning; error count >= 96) | SR.3 Transmission Complete Status (1=successful) 0xd9 = Stuff error during transmission in acknowledge slot segment That normally cannot / should not happen without a transmission attempt. So please verify there really was nothing going on. Maybe you didn't see the vehicle was actually active due to reduced log levels or missing log entries in the leaf code? There's the option the last TX frames were still waiting in the TX queue, issued when the car was switching off, but those would normally fail shortly after. The best option to capture anything going on with the bus over the night is activating an unfiltered can log to the SD card. When using crtd, that will also capture relevant events, errors and counter changes. The normal behaviour of a parked car is doing 12V battery maintenance every few hours, i.e. topping up the 12V battery from the main battery. That will normally also cause a limited CAN wakeup of the ECUs taking part in that process. Another option is some plugin or script doing a wakeup to query values. Yet another option is, the log entry wasn't caused by that error status, but by a counter change, e.g. txfail.
I'll now set can1 into listen mode to see what difference that makes.
That should only be done selectively if you still encounter car faults, to determine which bus possibly causes them. As you don't see any issues yet, proceed with both buses active to see if the new timing solved that. Regards, Michael Am 27.01.25 um 20:12 schrieb Chris Box via OvmsDev:
Hi.
Initial results after 27 miles on this new timing in the Leaf 2016. No in-car issues yet experienced. Stats are as below.
OVMS# can can1 status CAN: can1 Mode: Active Speed: 500000 DBC: none Interrupts: 20760013 Rx pkt: 20753155 Rx ovrflw: 6 Tx pkt: 2983 Tx delays: 103 Tx ovrflw: 0 Tx fails: 2527 Err flags: 0x008040d9 Rx err: 0 Tx err: 128 Rx invalid: 0 Wdg Resets: 0 Wdg Timer: 6 sec(s) Err Resets: 1 OVMS# can can2 status CAN: can2 Mode: Active Speed: 500000 DBC: none Interrupts: 12559716 Rx pkt: 12581843 Rx ovrflw: 0 Tx pkt: 88 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: 2 sec(s) Err Resets: 0
The logs show the usual mix of occasional can2 0x23401c01 & 0x22401c02 errors, indicating a busy state but not excessively so. I also saw 0x22001002 while driving this morning, in the middle of those others and a few minutes later when coming in range of home wifi.
The few log messages for can1 are of a different nature. 0x8048d9 was logged twice last night while parked and locked, with nothing going on. And this morning, 5.5 seconds after CAR IS OFF, it reports:
esp32can: can1 stuck bus-off error state (errflags=0x00040c00) detected - resetting bus
I'll now set can1 into listen mode to see what difference that makes.
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