[Ovmsdev] CAN drivers: fix & harmonize frame transmission failure handling

Fri Jan 8 02:53:07 HKT 2021

Chris,

thanks for testing & feedback.

You will still get multiple error log messages on a switched-off bus. 
I've kept it that way to get error log entries also when the error 
counter stays below the warning (96) or passive limit (128).

What your log shows is, that after 96 retries (and thus reaching just 
the error-warning threshold), the frame was finally transmitted 
successfully. You can see that from the txerr counter getting decreased 
to 95 finally. That's the way CAN works. The rxerr=1 is probably coming 
from an initial bit noise the transceiver sees on the bus.

After that, the bus should be awake, and further transmissions should 
get through directly. The rxerr should decrease to 0, the txerr decrease 
by 1 for each successful transmission and finally also reach 0. You can 
follow these by looking at "can can3 status".

So the fix seems to not have broken the transmission in this case, which 
is a good result. If the fix has a benefit for your wakeup sequence, it 
should work more reliably now, because it should now reliably get to be 
the first frame to be transmitted.

Regards,
Michael

Am 07.01.21 um 17:57 schrieb Chris van der Meijden:
> Hey Michael
>
> I fetched can-txfail-fix. It compiled without any problem. Flash worked
> and it boots.
>
> But it did not resolve the TX problems for me on CAN3 (VWUP T26A).
>
> Still getting the Errors from my TX workaround:
>
> I (94931) v-vweup: RemoteCommandHandler
> E (94931) can: can3: intr=1 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=8 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94931) can: can3: intr=2 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=16 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94931) can: can3: intr=3 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=24 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94931) can: can3: intr=4 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=32 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94931) can: can3: intr=5 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=40 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94941) can: can3: intr=6 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=48 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94941) can: can3: intr=7 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=56 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94941) can: can3: intr=8 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=64 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94941) can: can3: intr=9 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=72 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94941) can: can3: intr=10 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=80 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94941) can: can3: intr=11 rxpkt=0 txpkt=0 errflags=0x80001080 rxerr=0 txerr=88 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> W (94941) mcp2515: can3 EFLG: TX_Err_Warn EWARN
> E (94941) can: can3: intr=12 rxpkt=0 txpkt=0 errflags=0xa00510a0 rxerr=0 txerr=96 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> E (94951) can: can3: intr=14 rxpkt=0 txpkt=1 errflags=0x80001080 rxerr=1 txerr=95 rxovr=0 txovr=0 txdelay=0 txfail=0 wdgreset=0 errreset=0
> I (96931) v-vweup: Sent Wakeup Command - stage 1
>
> Sorry ...
>
> Greetinx
>
> Chris
>
>
>
>> o date and includes the BMW i3 code already.
>>
>> I need to get feedback from users of both can1 (esp32can) & can2/3/4
>> (mcp2515), as changes had to be made to both drivers.
>>
>> I'll quote from my commit:
>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/comm
>> it/c94592a11ad2c989e65313d23a8876cf38787d70
>>
>> Design goals:
>> - any TX can either fail or succeed, the result state is terminal
>> - the respective TX callback is called exactly once
>> - transmissions fail on reaching the error-passive bus state
>>    and on message/bus errors while in error-passive state
>> - a failed TX will be aborted (no retries after bus recovery),
>>    i.e. will be retried at most 128 times (in error-active phase)
>> - reduce excessive CAN error logging
>> - reduce excessive interrupt load with switched-off buses
>>
>> This results in the application being able to reliably detect a
>> switched-off vehicle bus by the TX callback's success indicator.
>> It also results in frames no longer being held in the TX buffer
>> or added to the TX queue when the bus is switched off. The
>> application can now rely on getting a clean bus state on every
>> reconnect, without any queued old frames to be sent automatically.
>>
>> Secondary benefit from aborting the transmission is, the module
>> doesn't need to handle the load from the continuously triggered
>> CAN error interrupts by retransmission attempts in error-passive
>> state.
>>
>> Reason for this was a) Steve's question on aborting transmissions /
>> flushing the queue and b) my new car now also switching off the bus,
>> with the annoying effect of a frozen can1 every 2-3 days, needing to
>> reboot the module. I'm not sure yet if the freeze issue is solved,
>> but I haven't had it since running these changes on my module.
>>
>> The other issue of the transceivers resending frames queued long ago
>> may have caused all sorts of strange & unrepeatable issues. I
>> remember the VW crew having problems that fell into this category.
>>
>> I've verified the new MCP2515 implementation only on my workbench
>> (with an Arduino as the CAN tester), so real life tests are
>> necessary.
>>
>> Thanks,
>> Michael
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210107/f0478032/attachment.sig>