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

[Steve Davies]

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/1007e870/attachment-0001.htm>