ERROR! Issues Sending SWCAN Frames with M2 Example


Hey guys, If any of you have tried to send SWCAN frames using Macchina’s included example, you may have noticed that there is never any data sent.

That’s due to the example having the wrong pins set for sending messages. Currently, the example sketch states these as the pins…


If you’d like your M2 to actually be able to send CAN frames, change them to this…


If someone on the M2 team sees this, please consider updating your examples. There is no doubt in my mind that this oversight has caused many people to fail in even the simplest of tests.

Thanks, and happy tinkering.


To add onto this,

The filtering using the mcp2515 library is not working correctly. And the “available()” function is also not completed.

After setting a mask of:
SWCAN.SetRXMask(MASK0, 0x7FF);

And filter of:
SWCAN.SetRXFilter(FILTER0, 0x644, 0);

I should be seeing every frame with an ID of 0x644 come through. Instead, its picking up a different frame ID and is also missing frames.
I have mixed about using both masks at the same time, and also all filters set, but still getting the same unpredictable behavior.

Now… what makes this really weird. Is that if I set the mask to 0, then every frame on the bus comes through, and no frames are dropped/missing at all.

A logical response is to just carry on with no filters, but that shouldnt have to be necessary. I have a feeling theres a couple bugs in this library causing the problems, so going to see if porting another mcp2515 library fixes the problem.

On a final attempt to add filtering, a firmware based filtering can be added in. Its not ideal a perfect solution but will do the same job.


This will be a @CollinK issue @Tazzi. Hopefully he will see this and chime in soon. I know he has been real busy the past couple days.

@th3magpi3 I will check that out sometime this week between classwork and try to update it if someone else doesn’t before I get to it.


Thanks Red.

Been playing with it quite a bit. And reading gmlan frames also breaks if you continue to write frames to the bus.

I suspect the write buffer ‘believes’ it has become full, even though it isnt. Once its full, you can no longer read frames from the bus. BUT… it will continue writing data to the bus.
Ontop of that, I can physically see on the network when this event occurs, the M2 actually has a ‘hickup’ and the frame sent out is slightly incorrect… as soon as that happens the M2 stops reporting the live data. This is confirmed with a separate logging tool

Basically I have a loop which sends a frame every 50ms, and reads all frames from the network. After about 20frames (few seconds) of writing and reading, the M2 will no longer process any more frames.

If I disable the writing part every 50ms, it will not have any problems with reading, left it running for over an hour to be certain.

Im adding in a little timer to enforce using the mcp2515 frame buffer rather than the software implementation… see if that helps solve this. Somehow I feel the interrupt and software buffer implementation are not playing nicely.


Seems the hardware TXD CAN buffer never frees up… its really odd. Only seems to occur on an interrupt.
Put a timer in for 30seconds… and at no point did it say it was free to transmit the frame which is extremely odd.


Hmmm. It looks like the Macchina version of the libraries are up to date with my version. I thought that everything was working but apparently not. I’ll try to get to the bottom of what is going on.


For what it’s worth I also had issues in Savvycan sending any SWCAN frames.


Another issue Iv found with SWCAN, is if the MCP2515 goes into Bus off mode, it cannot be brought out of it.

Bus off occurs after encountering too many errors. This could be due to not being connected to the bus and attempting to write too many times, or various other potential problems.

Trying to make something up to pull it out of this mode, but seems to be a common issue when reading up online for others using the same can controller.