(Michael, do you want to continue this thread on the mailing list or would you prefer I open a github issue?) On 2/28/21 11:39 PM, Michael Balzer wrote:
when connecting my bench module to my Arduino CAN shield, I need to add a terminal resistor in between. Did you try that?
My arduino board had a termination resistor, the pi shield did not.
You could then test if can2 & can3 are also affected. can1 is the internal bus of the ESP32 module, can2/3 are external MCP2515 buses accessed via SPI.
Great suggestion; adding a 120Ω termination resistor lets can2 or can3 exchange packets with the pi. (Well that plus learning how the can tx command works compared to the syntax of cansend -- it took me a bit to figure out why "can can2 tx standard 7DF 0201050000000000" was only sending 0x00...)
If it's can1 only, you could try running some CAN tester using the latest esp-idf driver.
Is there one you would suggest?
Maybe there are differences between the hardware revisions, revision 1 has some hardware bugs in the CAN controller as well.
I looked at the hardware errata: https://www.espressif.com/sites/default/files/documentation/eco_and_workarou... but I don't see any indication of V3-only canbus issues.
From a first look into the current esp-idf master, there is now a HAL for CAN (now called TWAI "two-way async interface" for whatever reason), and there seem to be some differences between the revisions. But AFAICT only minor ones:
https://github.com/espressif/esp-idf/blob/master/components/soc/esp32/includ...
The refactoring to twai is unfortunate as it makes it difficult to see relevant changes to can.c... I started by looking for the last version of can.c: git log --all --full-history -- components/driver/can.c that lead me to the last commit on 28-Dec-2020 (29e69a12d). Just prior to that were a couple of interesting commits: https://github.com/espressif/esp-idf/commit/4c3d49e3f083ac9c4114b4ef7d80433f... can: Fix semaphore take in critical section https://github.com/espressif/esp-idf/commit/3be94b69522b128da973ebee315b0593... Merge branch 'bugfix/can_critical_section_logs' into 'master' can: Fix critical section ESP_LOG functions I tried running a can.c from around then. With some include file change it compiled ok but trying to transmit a can frame on can1 results in loss of network connectivity and an infinite stream of can errors logged on the serial console. It might be just be the same errors but with interrupts locked out. Maybe you can make more sense out of these changes. Another strategy I want to try is to look for changes to twai.c, twai_hal_iram.c, and twai_hal.c between the refactoring and master. (A quick search didn't turn up many twai related github issues.) Here are some issues related to the above commits and can.c in general: https://github.com/espressif/esp-idf/issues/4412 ESP_LOG/vprintf fail inside critical section. It`s right? (IDFGH-2270) https://github.com/espressif/esp-idf/issues/4277 can.c calling xSemaphoreTake function from CRITICAL (IDFGH-2115) https://github.com/espressif/esp-idf/issues/3028 [TW#28658] Can driver bug I spent a little time decoding the errflags word. I started by verifying I could tx on can2 and receive with candump on my pi, then moved to can1. Here's an example first error message: E (460709) can: can1: intr=1 rxpkt=0 txpkt=0 errflags=0x8000d9 rxerr=0 txerr=8 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0 There are 15 log lines in all with intr= ramping up from 1 to 17. errflags changes from 0x8000d9 to 0x8440d9, then 0x8040d9 and finally 0x204c00. I wrote a quick python script to decode the values, I'll append some decoded values. Meanwhile given the molex series 2004 connectors I used for my car wiring it was simple to switch active polling from can1 to can2 which solves my theft alert issue for my cars. Craig ice 631 % Decode-ovms-can-errflags -dv 0x8000d9 0x8440d9 0x8040d9 0x204c00 # 8000d9 # err_irqs 80 (10000000) err_irqs: bus-err # status 0 (0) status: bus-on, ok, tx-idle, rx-idle, tx-incomplete, locked, no-overrun, rx-buf-empty # ecc d9 (11011001) ecc: ERR="other type of error", TX, FUNCTION="acknowledge slot" ******************************** # 8440d9 # err_irqs 84 (10000100) err_irqs: bus-err, err-warning # status 40 (1000000) status: bus-on, error, tx-idle, rx-idle, tx-incomplete, locked, no-overrun, rx-buf-empty # ecc d9 (11011001) ecc: ERR="other type of error", TX, FUNCTION="acknowledge slot" ******************************** # 8040d9 # err_irqs 80 (10000000) err_irqs: bus-err # status 40 (1000000) status: bus-on, error, tx-idle, rx-idle, tx-incomplete, locked, no-overrun, rx-buf-empty # ecc d9 (11011001) ecc: ERR="other type of error", TX, FUNCTION="acknowledge slot" ******************************** # 204c00 # err_irqs 20 (100000) err_irqs: passive-err # status 4c (1001100) status: bus-on, error, tx-idle, rx-idle, tx-complete, released, no-overrun, rx-buf-empty # ecc 0 (0) ecc: ERR="bit error", TX, FUNCTION="?"