CAN Bus Limitations

Quick question about the CAN filters.

When I try to put 64 arbitration ids in the mask filters, I get a exception. I think I reached the can filter limit so this is quite logical.

Is there a way to increase this amount or is it a hardware limitation? Also, if I have 63 mask filters, can I still use the range filters? If yes, how many?

They are hardware filters

They are combined together, if you have 63 mask then there is 1 left for range.

Also, if standard id then it is 128.

1 Like

One more thing :slight_smile:

The can peripheral stops working if you leave nothing connected to it for a while.

So if your device is listening on the fan bus and you leave the can cables disconnected for some minutes and plug it back in, the can messages don’t arrive in tinyclr.

I remember I had this issue with netmf as well, then I resolved it by resetting the can peripheral if I didn’t receive any messages for the last 5 seconds. This fix also works for tinyclr.

Is this something that’s normal in CAN (something similar to going into bus off after x can passive errors?)

I am still working on gathering more details on the problem, I’ll post them here as soon as I have them. :slight_smile:

This is not allowed. CAN is not designed like that.

I see. Let me tell you about my project a bit.

My module will be connected to a engine, a diesel engine made by caterpillar. It outputs data according to J1939.

When this engine is off, which happens of course, no can messages are sent out thus giving the same effect as having no cables connected (since there are no other nodes on the bus)

I have made this project before with a NXP IMXRT1062 microcontroller and that never had any problems if no CAN messages were received for a while.

i would have thought that with the engine off, the bus was still terminated with the correct resistance in the existing connected cables, so it’s not the same effect as having no cables?

Correct. That would be the difference between engine off and no cables. Thanks for clearing that up :slight_smile:

The thing is though, that the can peripheral in tinyclr requires actual messages to be sent. Even if the bus lines are properly terminated but no messages are sent, it still stops working after a while.

Do you have a termination resistor on your SITCore device that if you have disconnected from the bus it keeps the wires from causing noise?

Yes, the termination resistor on my board is enabled.

If so, and they do not send any messages then the bus should be fine. Please provide an example how the device becomes unresponsive after some time.

Make sure to subscribe to error events please.

Will do, but that might come until early January.

Going to start my 2 weeks vacation at the end of today :slight_smile:

Have fun and be safe… Happy holidays

1 Like

Same to you and the rest of the GHI team.

Happy holidays and stay safe! :smiley:

I have found a (small, I think) bug regarding the CAN filters.

If you have a filter active in CAN1, but then enable the CAN2 interface, the filter in CAN1 will stop working. It won’t let any message trough the filter at all.

Code that can be used to easily reproduce this with the SC20100S Dev board:

using GHIElectronics.TinyCLR.Devices.Can;
using GHIElectronics.TinyCLR.Pins;
using System;
using System.Collections;
using System.Diagnostics;
using System.Text;
using System.Threading;

namespace CANTest
{
    class Program
    {
        static void Main()
        {
            var can = CanController.FromName(SC20100.CanBus.Can1);

            var propagationPhase1 = 13;
            var phase2 = 2;
            var baudratePrescaler = 12;
            var synchronizationJumpWidth = 1;
            var useMultiBitSampling = false;

            can.SetNominalBitTiming(new CanBitTiming(propagationPhase1, phase2, baudratePrescaler,
                synchronizationJumpWidth, useMultiBitSampling));

            can.MessageReceived += Can_MessageReceived;
            can.ErrorReceived += Can_ErrorReceived;

            can.Filter.AddMaskFilter(Filter.IdType.Extended, 0x16E000A1, 0x1FFFFFFF);

            can.Enable();

            var can2 = CanController.FromName(SC20100.CanBus.Can2);
            can2.SetNominalBitTiming(new CanBitTiming(propagationPhase1, phase2, baudratePrescaler,
                synchronizationJumpWidth, useMultiBitSampling));

            can2.MessageReceived += Can2_MessageReceived;

            can2.Enable(); //If you comment out this line, the first CAN interface will let trough CAN messages again

            while (true)
            {
                Thread.Sleep(Timeout.Infinite);
            }
        }

        private static void Can_MessageReceived(CanController sender, MessageReceivedEventArgs e)
        {
            sender.ReadMessage(out var message);

            Debug.WriteLine("1: 0x" + message.ArbitrationId.ToString("X8"));
        }

        private static void Can2_MessageReceived(CanController sender, MessageReceivedEventArgs e)
        {
            sender.ReadMessage(out var message);

            Debug.WriteLine("2: 0x" + message.ArbitrationId.ToString("X8"));
        }

        private static void Can_ErrorReceived(CanController sender, ErrorReceivedEventArgs e)
            => Debug.WriteLine("Error " + e.ToString());

    }
}

If the line can2.Enable() is commented out, the filter of CAN1 works flawlessly. But when we activate CAN2, the filter does not let any messages trough.

Is this a software bug that can be fixed or are we limited by the hardware here?

1 Like

We will check but sound like it is a bug.

1 Like

Which version are you using? Because there was a major change on the filters.

Latest preview, 2.1 preview 2

How about the issue CAN has no communication few hour then stop receiving? Do you still see that issue?

I’ll dive into more detail for this issue tomorrow.