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

[Steve Davies]

Hi Michael,

Here's the log from a test on my car with your branch

I started the car, left it for a while, then shut it down and waited until
the OBD-II first went to "not getting replies to my requests" and then to
"not sending anything at all".

Hope its helpful.

https://drive.google.com/file/d/1AavD41HCykYrn-BxQXNufu2dT_UVCXYU/view?usp=sharing

Steve


On Fri, 8 Jan 2021 at 08:22, Steve Davies <steve at telviva.co.za> wrote:

> Hi Michael,
>
> The change looks helpful, thanks.  I'll try it during the course of the
> day.
>
> It does prompt me to ask a question that I had - On the i3, if you do
> something like send a lock from the key or the Connected Drive APP then the
> OBD-II comes alive but goes asleep again in less than a minute.
>
> if I have a PID that I poll infrequently - say every 120 seconds.  What
> happens in this case?  Would they be seen as "overdue" when the bus comes
> alive and polled immediately, or is it a matter of luck if the 120th tick
> arrives at a time when the bus is alive?
>
> If the latter I need to poll even things like the VIN every 10 seconds to
> make sure I get it before the bus goes to sleep again.
>
> Thanks,
> Steve
>
>
> On Thu, 7 Jan 2021 at 18:22, Michael Balzer <dexter at expeedo.de> wrote:
>
>> Everyone,
>>
>> please pull & test the new "can-txfail-fix" branch. It's up to 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/commit/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
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210108/9f644b09/attachment-0002.htm>