[Ovmsdev] esp32can issue

Stein Arne Sordal ovms at topphemmelig.no
Thu Aug 16 22:00:58 HKT 2018


3.1.008 with some small custom mods.
I will update later today.

-Stein Arne Sordal-


> On 16 Aug 2018, at 15:52, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> What version firmware are you running? Those err flags seem too short.
> 
> On 16 Aug 2018, at 9:41 PM, Stein Arne Sordal <ovms at topphemmelig.no <mailto:ovms at topphemmelig.no>> wrote:
> 
>> Hi
>> 
>> I tried the "can can2 start active 500000” command.
>> The first time it stopped again almost instant.
>> The second time it worked for a minute.
>> 
>> I got two different error flags:
>> 
>> CAN:       can2
>> Mode:      Active
>> Speed:     500000
>> Interrupts:               16480
>> Rx pkt:                   16643
>> Rx err:                       0
>> Rx ovrflw:                   37
>> Tx pkt:                     231
>> Tx delays:                    0
>> Tx err:                     128
>> Tx ovrflw:                    0
>> Err flags: 0x8015
>> 
>> CAN:       can2
>> Mode:      Active
>> Speed:     500000
>> Interrupts:                9164
>> Rx pkt:                    9230
>> Rx err:                       0
>> Rx ovrflw:                   17
>> Tx pkt:                      25
>> Tx delays:                    0
>> Tx err:                       0
>> Tx ovrflw:                    0
>> Err flags: 0x2040
>> 
>> 
>> Regards,
>> Stein Arne Sordal
>> 
>> 
>>> On 16 Aug 2018, at 13:05, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>> 
>>> The mcp2515 issues are probably different than esp32can, but similar logic can probably be used to address them both.
>>> 
>>> After a week in my car with three buses running, can2 locked up today. Here is the status:
>>> 
>>> OVMS# can can2 status
>>> CAN:       can2
>>> Mode:      Active
>>> Speed:     500000
>>> Interrupts:               40069
>>> Rx pkt:                   40429
>>> Rx err:                       0
>>> Rx ovrflw:                    0
>>> Tx pkt:                       0
>>> Tx delays:                    0
>>> Tx err:                       0
>>> Tx ovrflw:                    0
>>> Err flags: 0x01000001
>>> 
>>> OVMS# can can3 status
>>> CAN:       can3
>>> Mode:      Active
>>> Speed:     125000
>>> Interrupts:             5003600
>>> Rx pkt:                 5003610
>>> Rx err:                       0
>>> Rx ovrflw:                    0
>>> Tx pkt:                       0
>>> Tx delays:                    0
>>> Tx err:                       0
>>> Tx ovrflw:                    0
>>> Err flags: 0x01000001
>>> 
>>> CAN3 was operating normally. Flags identical.
>>> 
>>> I fixed this with:
>>> 
>>> OVMS# can can2 start active 500000
>>> Can bus can2 started in mode active at speed 500000bps
>>> 
>>> OVMS# can can2 status
>>> CAN:       can2
>>> Mode:      Active
>>> Speed:     500000
>>> Interrupts:                 831
>>> Rx pkt:                     831
>>> Rx err:                       0
>>> Rx ovrflw:                    0
>>> Tx pkt:                       0
>>> Tx delays:                    0
>>> Tx err:                       0
>>> Tx ovrflw:                    0
>>> Err flags: 0x01000001
>>> 
>>> No need to power on/off.
>>> 
>>> For mcp2515, I’ll try to add a ‘kick’ function able to try to read the status registers and restart as appropriate. That should give us more information.
>>> 
>>> Regards, Mark.
>>> 
>>>> On 16 Aug 2018, at 4:58 PM, Tom Parker <tom at carrott.org <mailto:tom at carrott.org>> wrote:
>>>> 
>>>> On my Leaf the bus seems to stop quite often, so the reset would have to operate quite often too. Perhaps increment a metric when the reset fires so we can monitor how often it is happening?
>>>> 
>>>> On 16/08/18 01:46, Mark Webb-Johnson wrote:
>>>>> Sorry, forgot to mention: another option is to poll the bus manually if an interrupt hasn’t been received in N seconds. Check the status registers and if everything is not perfect then reset the controller.
>>>>> 
>>>>>> On 15 Aug 2018, at 9:45 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>>> 
>>>>>> This was my worry for both esp32 can and mcp2515. We get an interrupt, but for some reason the status is not showing anything to do, so we return from the interrupt. Then, the status changes. Or, for a particular status we had to do something that we didn’t. The bus is locked up, and the interrupt never fires again, so we never get called. I wonder if we just fired the interrupt handler again manually, would it recover?
>>>>>> 
>>>>>> When this happens, do we need to power off then on the can bus, or is a ‘can canX stop’ ‘can canX start …’ sufficient?
>>>>>> 
>>>>>> Perhaps a general solution would be a watchdog. If the CAN bus does not receive anything for N seconds (perhaps 60), then restart the controller? We could simply protect it from restarting twice (a simple check of the counters), so worse case this would restart once 60 seconds after a bus normally went idle. Or is that too kludgy?
>>>>>> 
>>>>>> Regards, Mark.
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> _______________________________________________
> 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/20180816/433a7770/attachment.htm>


More information about the OvmsDev mailing list