[Ovmsdev] Can buses stop after some time
Mark Webb-Johnson
mark at webb-johnson.net
Thu May 24 08:28:09 HKT 2018
The OBDII client should determine the bus speed and the ECU side only needs to support one speed.
Clients typically do this in one of two ways:
Set CAN controller to ‘listen’ mode, then loop through supported bus rates, listening for a correctly formatted CAN message to let you know you found the right rate. If found, exit the loop.
Set CAN controller to ‘active’ mode, then loop through supported bus rates, polling for OBDII data and ignoring errors. If you get a valid response, exit the loop.
Obviously #1 is the least noisy approach, and the least likely to interfere with other vehicle systems, but won’t work on purely active polling can buses with nothing else active on the bus. I guess some clients may employ both approaches.
I suspect that your HUD is working cleanly because it tries 500K rate first, so doesn’t generate errors.
It would probably be worth us transmitting a CAN bus heart beat every few seconds when obd2ecu is started, 12v external power is on, but we haven’t heard from the HUD in a while. That would probably help clients lock onto us quicker.
Regards, Mark.
> On 24 May 2018, at 4:54 AM, Greg D. <gregd2350 at gmail.com> wrote:
>
> Hi Mark,
>
> The OBD2ECU task assumes that "all" HUDs and such devices operate at 500k. Are you aware of any that don't (can't) operate at that speed? I was hoping I wouldn't have to support multiple speeds, especially autosensing them.
>
> BTW, I have not seen any problems connecting an OBDII Dongle to the OVMS and letting it do its default scan through the various rates in order to connect. It just takes longer than it would if (as I usually do) tell it what rate and frame size to use. The various frames and speeds tried before figuring out the right one don't seem to bother it.
>
> Greg
>
>
> Mark Webb-Johnson wrote:
>> I am also now seeing this.
>>
>> Trying out the OBD2ECU HUD cables, I was having problems getting it to work. Those HUDs try to transmit at different baud rates, to probe for what is correct, and that is causing errors at our end. Once we get those errors, seemingly we can’t recover. A ‘can can3 start active 500000’ fixes the issue and the HUD connects.
>>
>> It looks something like this:
>>
>> OVMS# can can3 status
>> CAN: can3
>> Mode: Active
>> Speed: 500000
>> Interrupts: 1
>> Rx pkt: 0
>> Rx err: 105
>> Rx ovrflw: 0
>> Tx pkt: 0
>> Tx delays: 0
>> Tx err: 0
>> Tx ovrflw: 0
>> Err flags: 0x8000
>>
>> Or this:
>>
>> OVMS# can can3 status
>> CAN: can3
>> Mode: Active
>> Speed: 250000
>> Interrupts: 146
>> Rx pkt: 0
>> Rx err: 128
>> Rx ovrflw: 0
>> Tx pkt: 0
>> Tx delays: 0
>> Tx err: 0
>> Tx ovrflw: 0
>> Err flags: 0x800b
>> E (713021) canlog: Error can3 intr=1 rxpkt=0 txpkt=0 errflags=0x8000 rxerr=1 txerr=0 rxovr=0 txovr=0 txdelay=0
>> E (713021) canlog: Error can3 intr=2 rxpkt=0 txpkt=0 errflags=0x8000 rxerr=2 txerr=0 rxovr=0 txovr=0 txdelay=0
>> E (713021) canlog: Error can3 intr=3 rxpkt=0 txpkt=0 errflags=0x8000 rxerr=4 txerr=0 rxovr=0 txovr=0 txdelay=0
>> ...
>> OVMS# can can3 status
>> CAN: can3
>> Mode: Active
>> Speed: 250000
>> Interrupts: 3757
>> Rx pkt: 1
>> Rx err: 128
>> Rx ovrflw: 0
>> Tx pkt: 1
>> Tx delays: 0
>> Tx err: 0
>> Tx ovrflw: 0
>> Err flags: 0x800b
>> ...
>> OVMS# can can3 status
>> CAN: can3
>> Mode: Active
>> Speed: 250000
>> Interrupts: 3775
>> Rx pkt: 10
>> Rx err: 128
>> Rx ovrflw: 0
>> Tx pkt: 10
>> Tx delays: 0
>> Tx err: 0
>> Tx ovrflw: 0
>> Err flags: 0x800b
>>
>> And then the can bus dead (until ‘can start …’ to reset it).
>>
>> Good news is that with those HUDs, it is very easy to recreate the fault condition. I’ll see what I can do to find out what is going on. My guess is we are not clearing the MCP2515 error condition correctly. I will try to find out what is going on...
>>
>> Regards, Mark.
>>
>>> On 14 May 2018, at 6:17 PM, Tom Parker <tom at carrott.org <mailto:tom at carrott.org>> wrote:
>>>
>>> On 14/05/18 20:36, Stein Arne Sordal wrote:
>>>
>>>> I also tried to raise the stack size to 6144.
>>>> It seems like it got worse…Can buses (RX) stops working more often. TX is fine.
>>>
>>> I don't see an improvement either. I wrote the new firmware with updated sdkconfig at about 3pm yesterday and it rebooted and lost the state of charge metric at 8:45pm, the car woke up at midnight and started charging, providing data for the SOC metric, during the charge there were a couple of gaps in the telemetry, charging finished at 3:10am and the OVMS rebooted at 3:45. The OVMS then stopped sending telemetry completely at 7:20 am when the car was switched back on. I had a chance to plug a laptop in and the module was unresponsive on the serial port.
>>>
>>> I'm not sending the monotonic metric so it's only possible to see the first reboot after the car is switched off (when it forgets the SOC).
>>>
>>> I've built a version of the firmware with most things turned off (and found vehicle depends on webserver and webserver depends on OTA) I'll see how that goes tonight.
>>>
>>> Otherwise I'll get the datalogger out and/or try the sdcard logger again.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20180524/c33ef9a7/attachment.htm>
More information about the OvmsDev
mailing list