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
…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
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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev