Order of CAN-Frames are mixed up

[DRitter]

Hello fellow developers,

for my project I'm using a Raspbarry Pi 3b with a Tinkerforge HAT Brick and a Tinkerforge CAN 2.0 Bricklet. This setup is used as an UDP<->CAN Gateway.

I'm simulating devices on a simple windows computer. The data is send by UDP to the Raspbarry which converts my data to CAN-Frames and puts them on the CAN-Bus to communicate with the ECU.

Vice Versa the ECU sends CAN-Frames on the CAN-Bus, the Pi converts those CAN-Frames to UDP-Packets and sends them by ethernet to my simulation computer.

Everything works fine until we start nightly runs. After a while (hours) the CAN-Bricklet puts the CAN-Frames in a wrong order on the CAN-Bus.

How did we find this out:
I'm simulating devices which send CAN-Frames with Sequence-Numbers. After one night the ECU receives CAN-Frames with completly mixed up sequence numbers. E.g: 7 -> 2 -> 3 ->8 and so on.

I logged the elements of the CAN-Queue before my script writes them on the CAN-Bus. The queue is fine, all frames are in the right order. It seems the CAN-Driver has some issues... 

Restarting my script workes to fix it for some hours again.

The CAN->UDP direction works fine though. Receiving CAN-Frames and converting them to UDP-Packages still works.

Is this a common problem or I'm the only one facing this issue?
We also tried to change the HAT and bricklet to avoid any hardware problems but no change...

If anyone has any ideas how to narrow to the core of this problem I appreciate.

Thank you very much in advance.
Daniel

[photron]

This is not a common problem. It's the first time I hear about it. But I might have a hunch, about what might cause this.

When the problem occurs, do you see a change in the CAN error counters of the Bricklet (function get_error_log)?

By default the Bricklet uses 8 hardware write buffers. Does it make a difference if you reduce the number of write buffers to 1 (function set_queue_configuration, parameter write_buffer_size = 1)?

Does your script reset the Bricklet on start?

[DRitter]

First of all thank you for the quick answer, sorry I didnt received any email to replay immediately.

Zitat

Does your script reset the Bricklet on start?

yes it does.

The queue is currently configurated like that:

self.can = BrickletCANV2(uid, device.device)  # Create device object
self.can.set_queue_configuration(
	config.TINKERFORGE_CAN_WBUF,
	config.TINKERFORGE_CAN_W_TIMEOUT_MS,
	config.TINKERFORGE_CAN_W_BACKLOG,
[
  config.TINKERFORGE_CAN_DATA_RBUF,
  -config.TINKERFORGE_CAN_REMOTE_RBUF
],
	config.TINKERFORGE_CAN_R_BACKLOG)

## Hardware write buffer in frames [0;32]
TINKERFORGE_CAN_WBUF: Final = 16

## If the message could not be send after this time, the message will be discarded.
TINKERFORGE_CAN_W_TIMEOUT_MS: Final = 200

 

## Software write backlog in frames [0;768]
TINKERFORGE_CAN_W_BACKLOG: Final = 383

 

## Hardware read data frames buffer in frames [0;32]
TINKERFORGE_CAN_DATA_RBUF: Final = 15

 

## Hardware read remote frames buffer in frames [0;32]
TINKERFORGE_CAN_REMOTE_RBUF: Final = 1

 

## Software read backlog in frames [0;768]
TINKERFORGE_CAN_R_BACKLOG: Final = 383

 

I will start a new run tonight as I changed the TINKERFORGE_CAN_WBUF: Final = 1. Hopefully it will fix it, I'll let you know ;)

 

[DRitter]

Today after a nightly run I entered the lab and the ECU is not in failure mode. It seems setting the write buffer to 1 fixed the problem. Thank you very much. We will still keep an eye on it.

But this raises the question why does this happen, maybe a bug in the internal process routine of the write buffer? Perhaps there was a hint in the documentation I did not see.

For my understanding the write buffer is nothing but a queue which should process the data with FIFO, which it does in the beginning.

The read buffer is set to 15 as well and does not raise any problems...

Thank you very much again! The thread can be closed successfully for now =)