[Ovmsdev] GPS theft alert

[Craig Leres]

(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_workarounds_for_bugs_in_esp32_en.pdf

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/include/soc/soc_caps.h#L221

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/4c3d49e3f083ac9c4114b4ef7d80433f779cd477
     can: Fix semaphore take in critical section

 
https://github.com/espressif/esp-idf/commit/3be94b69522b128da973ebee315b0593e3388727#diff-d2f18f80bb04b27dc1bf304f87de49bd8f804a76c20a1ce83f181972cc1616a4
     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="?"