Giters

107-systems / 107-Arduino-MCP2515

Arduino library for controlling the MCP2515 in order to receive/transmit CAN frames.

Home Page:https://107-systems.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"Stale" interrupt situation using sniffer example. ESP32

czmorris opened this issue · comments

commented

I am curious if anyone has observed something like this...

When running the sniffer example I get a few transmissions and then it stops and I find that the MCP2515 Interrupt pin is LOW.
It appears to be a missed interrupt which stops the library. I added some test code to check for the stale interrupt pin and run the handler to get things going again and it works fine.

Note that it is possible some other hardware event is the root cause. I just found it an interesting observation.

Setup:
Custom Board, ESP32 with MCP2515 and MCP2551 to an automotive canbus.
Using HSPI on the ESP32 for the MCP2515 Interface.

commented

Hi 👋 Your issue report is quite similar with one I received from @generationmake 👋. However, I've been looking at the code and I'm unable to determine any bug. I'm wondering though, how long each of you is staying within the ISR? If the code executed within the on_rx_buf_full callback takes a long time to execute (in fact so long that meanwhile another CAN frame has been received) than the INT line will stay continuously LOW.

A workaround for you might be to change this line like

-attachInterrupt(digitalPinToInterrupt(MKRCAN_MCP2515_INT_PIN), onExternalEvent, FALLING);
+attachInterrupt(digitalPinToInterrupt(MKRCAN_MCP2515_INT_PIN), onExternalEvent, LOW);

However, I would not recommend it. Cutting down the amount of processing you do in the callback should do the trick.

commented

Hi.
I experienced a similiar issue with the example posted here: https://forum.uavcan.org/t/hardware-example-using-uavcan-v1-on-arduino/1052/3
It seems like receive is stopped after some time. Messages are still transmitted but the Arduino doesn't react to received messages.

But I haven't investigated further.
In my example it takes a few hours (3 - 6 hours) until the error occurs.

commented

In my case I haven't added any code to the callback yet. I'm running the straight example. It happens pretty quickly(seconds). I'm connected to the canbus of an electric motorcycle which is pretty active though. I thought about interrupting on LOW but I decided to just use some "watchdog" logic to kick it once when it detects it's stuck. When I get a chance I'll see if I can add some debug GPIO and watch it with the logic analyzer. That should give me some idea of the timing.

commented

Serial output is slow - given enough CAN bus activity you'll quickly get to the situation you describe.

commented

The logic analyzer confirmed the ISR was running too long. The bursts of can data on the bike I am talking too can happen rapidly. Even making the ISR extremely short I was getting interrupt watchdog resets on the ESP32 because it was spending so much time handling interrupts. For my application its acceptable to miss a few CAN messages and I don't need super critical timing. So instead of using the ISR I am using a dedicated task to monitor the MCP interrupt pin. :) Thanks.

commented

Thank you for confirming, I suspected as much. Another workaround might be to just push the CAN frames into a ringbuffer and consume the content of the ringbuffer in the main loop. All in all the example is just a quick demo how to use the library, not a ready-made solution fitting all requirements ;)