Event Handler thread priority (CAN)

NETMF & Gadgeteer
1

Hi,

We’re using a Cobra III (G120) to make a controllable CAN node. The CAN network contains multiple functions (diagnostics, CAN network management and various functions) and so we need multiple message handlers. Owing to the way the CAN message handler is implemented, when the CAN Message Received event is fired, the CAN messages need to read out of the receive buffer. Once this happens the CAN messages need distributing to the various message-specific handlers. In order to do this we have implemented a class which responds to the CAN received events by reading out the CAN Message Received and fires out events according to the specific handlers registered, defined by CAN Message ArbId.

To further complicate matters, the product is controllable over serial, so we also have a serial event handler.

The problem we have is that the reaction to the diagnostic CAN messages are being responded to too slowly.

This use case in our system looks like this:

Serial Link Diagnostic function request (rx)

  • SerialDataReceivedEventHandler
    • JNX.JNX_SerialCommands.HandleSerialRequests
      • JNX.DiagnosticsHandler.RunDiagnostic
        • JNX.JNX_CAN.SendMessage
          • GHI.ControllerAreaNetwork.SendMessage
            • CAN network (diagnostic CAN message tx)

CAN network (diagnostic CAN message rx)

  • GHI.ControllerAreaNetwork.MessageAvailable
    • JNX.JNX_CAN.MessageAvailable
      • JNX.DiagnosticsHandler.MessageReceived (process response)
        • JNX.JNX_CAN.SendMessage
          • GHI.ControllerAreaNetwork.SendMessage
            • CAN network (diagnostic CAN message tx)

This last CAN message is taking a very long time to be sent: 1-6s!

Please can you advise where I should start searching?

One question I had was whether I could raise the GHI.ControllerAreaNetwork.MessageAvailable event handler thread priority, and also the subsequent JNX.DiagnosticHandler.MessageReceived event handler? Or would I need to set the Thread priority every time the event handler is fired?
Equally, I would like to lower the serial event handler too.

Thanks in advance,

Jason

2

Before investigating the software, are you sure the CAN bus is healthy? It is possible that there are many error frames on an already busy bus causing the messages to be delayed 6 seconds.

Try connecting another note on the exact same setup and send a message periodically. Does that message get any immediately and your see that on a CAN bus analyzer?

A message on CAN is not sent immediately. Only when the bus is free and the it gets sent successfully with acknowledgment.

3

Thanks Gus,

I am working with Jason on this. To expand in a little more detail…

We have a specific requirement on a CAN diagnostic message where we are receiving multi-byte frames. The sender will send a first frame, and then we need to respond within a few ms with a flow control frame, and then the sender will send the rest of the frames. I have an ECU flasher working with this, and, in the CAN receive event handler, we send out the flow control frame if the incoming message requires it. This works fine for the ECU flasher as that is pretty much all it is doing at the time (just the CAN sequences for flashing).

Our problem comes in a more-complex application where there are several periodic CAN messages also being sent from a main loop . We also have some event-based handlers, such as the serial control, but these should hopefully not be coming in to play at this point. However, if we send out the flow-control frame as soon as we see it in the CAN received event handler, it sometimes goes out in a few ms (good), but often takes several hundred milliseconds to be sent, which is too late and the sender will have aborted the message.
The CAN is error-free, and the main CAN transmit loop is taking about 4ms normally, so that doesn’t explain the delay. If I send a test message as soon s the CAN receive event handler is triggered and then a second test message later in the process, I can see that the first message can take a few ms or a few hundred ms, and the second message always takes a ms or two. So, it would appear that the issue is that the CAN receive event handler sometimes takes time to fire, and then runs quickly as expected.
On the CAN receive side, we are only listening for these diagnostic messages, and a couple of other network management frames (about ten a second), so the incoming traffic processing should also not be affecting it.

What we are hoping for is some way to ensure that, when the CAN is received, the CAN receive event handler is fired with the highest priority, over the “normal” CAN sending thread, and any other event handlers that may be about to trigger, so we can get the flow-control frame out as quickly as possible. Is this something that can be configured when setting up a specific event handler, or can we fake it by de-prioritising the other threads?

Sorry for the long-winded note - I was hopefully covering any background that may be relevant, and probably a lot that is not, just in case :slight_smile:

(For info, we added an extra level of CAN receive event handler, because we found that the GHI event handler would not handle subscriptions from more than one thread, If we subscribed 2 threads to the event handler, only one would get the notification)

Thanks in advance

Nick

4

Do you use networking? Graphics? What other features beside CAN and uart?

5

SD Card, USB Data Storage, I/O

No networking, nor graphics.

[EDIT]
To be clear, when the CAN functionality is running, there are minimal other feature-sets in operation - the SD/USB access is for configuration only. The I/O is for updating our screen, but this is executed AFTER any CAN responses are transmitted (if required).

6

Here is what I am thinking, as we are full force on TinyCLR, if you do the switch then we can help you in testing the functionality plus we can do whatever internal needed improvements on the core. You basically get free consultation since we need to work to prove TinyCLR quality in several industries and commercial settings. Would this work for you or NETMF is a must?

PM me with contract info if you like to discuss options.

7

Hi Gus,

Have PM’d you and emailed you - no reply.

Jason

8

I have replied to your PM days ago. Please check it.

9

Mix-up in comms - have replied.

Thanks

1 Like