WrongSequenceNumberError

[jagauthier]

I realize this error condition is intentional. But, by nature CAN may not send messages orderly.
I was able to trigger this with a simple message:

data = b'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'
data = data + data

WARNING:root:IsoTp error happened : WrongSequenceNumberError - Received a ConsecutiveFrame with wrong SequenceNumber. Expecting 0x3, Received 0x8
WARNING:isotp:Received a ConsecutiveFrame with wrong SequenceNumber. Expecting 0x3, Received 0x8

candump shows:

  can0  100   [8]  10 48 30 31 32 33 34 35
  can0  456   [3]  30 08 00
  can0  100   [8]  21 36 37 38 39 41 42 43
  can0  100   [8]  22 44 45 46 47 48 49 4A
  can0  100   [8]  28 4A 4B 4C 4D 4E 4F 50

[pylessard]

Hi
Why would CAN not send message orderly? That sounds more like a design flaw in the CAN driver IMO.

CAN is designed to be reliable. Unwanted unordered message is a serious weakness.
I understand that you may assign different ID to different mailboxes and let the hardware send whenever it is convenient, but this would be a case where unordered message are expected. In the case of a ISOTP communication, a stream of CAN message all have the same ID and they are expected to be ordered, so it is the task of the driver to send them through the same mailbox

[pylessard]

[jagauthier]

Will you post a link to that document? I don't have enough context. CAN doesn't have sequence numbers.

[pylessard]

This is ISO-15765-2:2016, the standard that defines the ISO-TP protocol. Unfortunately, the document is licensed, but if you look hard enough, you may find something, some chinese friends are not as respectful of western paywall as good will would dictate ;) .

ISO-TP is a transport layer that goes above CAN layer. Sequence number is defined in the IsoTP protocol only.

https://www.iso.org/standard/66574.html

[jagauthier]

Although, you said something that struck me: "..so it is the task of the driver to send them through the same mailbox"
I did not know this. I need to check the driver implementation to make sure that ISOTP messages are being sent out the same mailbox. Because I think at the moment they are being sent out whenever mailbox is free they want.

One of my devices is SLCAN, and I'll need to check it's code.

My third device, which is a socketCAN device is working perfectly. I am going to chase down the mailbox issue. Thanks for the tip! I almost didn't post anything at all and I would have been frustrated trying to solve this.

[pylessard]

Alright!
Good luck with that. I'll let you close this issue whenever you believe it is relevant.

Keep me updated.

[jagauthier]

It looks like I have a bit of coding to do to - but I can verify the backend code is using whatever mailbox it wants. I am going to have to write some code to handle this, which is inconvenient.

[pylessard]

Generally, what I see is that there's a queue for each Transmit mailbox, then each message ID is assigned to a specific mailbox, meaning it is affected to the right queue, then the driver pops from queue A to write to mailbox A, queue B for mailbox B, etc.

[pylessard]

If I can add, generally, you need very few Transmit mailbox and a lot of receive mailbox. If your software is able to write to the mailbox as fast as the CAN bus transmit, you only need 1 mailbox. Adding mailboxes just reduces the number of interrupt/polling call t the driver. 4 is, I think, enough for most use case.

[pylessard]

@jagauthier : Do you care sharing the root cause how you fixed it?

[jagauthier]

In my ecosystem I am using STM32 MCPUs which have bxCAN hardware in them. In this CAN messaging system there are transmit mailboxes. Using the built-in API provided by STM32 to submit a CAN message to a mailbox did not allow you to specify the mailbox, nor have any control over it. So you could submit 3 messages, and each message would go to a different mailbox and those mailboxes would not have a particular sending priority. Therefore, message 3 might be sent before message 1. This, obviously, breaks ISOTP.
My solution was to create a linked list of transmittable messages. Each arbitration ID was assigned to a mailbox (based on a small algorithm that kept track of it's use). Then when a message was submitted, that arbitration ID would only go out that mailbox and it's order of being sent was respected with the order it was submitted.

Moving forward, I've changed my STM32 ecosystem to only using their CANFD implementation. Their CANFD implementation does not use mailboxes, and instead it uses a FIFO. This eliminates the problem and vastly simplified my code.

Plus, their CANFD implementation has more robust filtering available. So, I only use STM32 MCPUs with CANFD capabilities now. (STM32G series, for instance)

[pylessard]

Very interesting! Thank you for the feedback, might be useful to others