[Ovmsdev] CAN-3 broken again?

[Mark Webb-Johnson]

In vino veritas.

> On 16 Jan 2018, at 11:48 AM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> Hi all, (but mostly Michael...),
> 
> I'm sitting here at my workbench, with a glass of Merlot in one hand, and a red velvet and white chocolate cookie in the other, staring at a yet-again hung CAN3 bus on the v3 module.  A sequence of multiple Transmits, closely spaced, can cause the chip to stop processing (issuing) interrupts, hanging the receive side, and making the transmit side operate strangely.  Nothing I do seems to help, and Google searches are not encouraging.
> 
> Looking at the chip's programming manual, I start to see a lot of "feature" (complication) in the transmit buffering.  Multiple priorities, etc., none of which we are (should be) using.  So, since Michael has implemented a very efficient excess-frame queuing mechanism, how about we just use a single transmit buffer at a time, and queue the rest?  Not quite as good as double buffering the transmit, but still a lot faster than the original fixed delay.  Will it fix the hang?
> 
> Bingo!
> 
> Fix is simple and implemented, and seems to work.  I will do some more testing before committing later tonight.  Perhaps another glass of Merlot is in order. Or, maybe an old-vine Zin...
> 
> Greg
> 
> 
> Michael Balzer wrote:
>> Greg,
>> 
>> ah yes, the esp-idf currently doesn't implement oneshot interrupts on levels, we need to do that ourselves.
>> 
>> Something along the base line of this:
>> 
>> https://github.com/espressif/esp-idf/issues/1234#issuecomment-342320583 <https://github.com/espressif/esp-idf/issues/1234#issuecomment-342320583>
>> 
>> …just with reversed logic, as we get triggered on low.
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 14.01.2018 um 20:36 schrieb Greg D.:
>>> hi Michael,
>>> 
>>> Good try, but the whole system hangs, so I'm guessing that we're stuck in an infinite interrupt loop.  But that suggests that the issue is related to unbalanced interrupt processing somehow.
>>> 
>>> I'm going to try for some diagnostic logging once it gets stuck, and see if I can identify its state.  The absolute reproducibility of the base issue leads me to think the reported empty interrupt issue (your prior email) is probably not it, but rather the driver is not handling some confluence of events properly.  I have no trouble running the HUD display, for example, but it doesn't produce the rapid transmit frames of the OBDWiz dongle.  Something about the transmit side is messing up the receive...  I wonder if we're getting an interrupt for both the last Tx frame being sent and the VIN request PID being received at the same time?  Transmit interrupts don't check for receive, and vice-versa.
>>> 
>>> Will report back later today...
>>> 
>>> Greg
>>> 
>>> 
>>> Michael Balzer wrote:
>>>> Greg,
>>>> 
>>>> here's another report of level triggering solving the issue: https://community.nxp.com/thread/456907 <https://community.nxp.com/thread/456907>
>>>> 
>>>> Can you please give that a try? I.e. change line 77 to:
>>>> 
>>>>   gpio_set_intr_type((gpio_num_t)m_intpin, GPIO_INTR_LOW_LEVEL);
>>>> 
>>>> 
>>>> I'll also get a DB9 plug to implement Marks test solution.
>>>> 
>>>> Regards,
>>>> Michael
>>>> 
>>>> 
>>>> Am 14.01.2018 um 17:52 schrieb Michael Balzer:
>>>>> 
>>>>>> Hmmmm, I think level triggered interrupt would help here.
>>>>> 
>>>>> We currently let the interrupt trigger on the negative edge (line 77). Maybe GPIO_INTR_LOW_LEVEL can help?
>>>> 
>>>> -- 
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180116/0fc9b764/attachment.htm>