VT example does not work properly

[l0815o]

Hi,

thanks for creating this library!

I'm trying to use the VT example sketch, but I'm running into a strange problem. Teensy 4.0 is my target and the sketch is running as far as I can see it from the serial monitor in the Arduino IDE.

This is the output, which I get there:
[...]
[Info]: [VT]: No version label from the VT matched. Client will upload the pool and store it instead.
[Debug]: [ETP]: New ETP Session. Dest: 38
[Error]: [ETP]: Received an abort for an session with PGN: 59136
[Debug]: [ETP]: Session Closed
[...]

It seems that the object pool upload is not working properly, so I tried to analyse it. I made a CAN trace and it the message order in the ETP seems to be chaotic.

Do you have any idea, what is causing this behaviour? I haven't changed the example and the CAN is also properly terminated. I hope you can help me as I'm not an expert in terms of the Teensy hardware.

[ad3154]

Hello! If you're willing to try a few things, I think we can figure this out!

FlexCAN seems like it can get weird about message ordering when message volume is high, which is unfortunate for us since our library requires messages be sent perfectly sequentially. I think we can maybe do some things about this.

• I can see in their driver's header file that we can maybe enable a FIFO instead of their message mailbox functionality, so maybe that should be the first thing we try? I have some other updates to pull into the Arduino library from the main repository anyways, so I can work on that.
• If that doesn't solve the issue, then we can always add some code to the example to throttle the ETP a little to take some load off the FlexCAN driver, but that's not super ideal.
• We can also mess with the Tx queue size within the FlexCAN driver, as it's currently set to 256 messages, which is suspiciously close to the boundary of 1 ETP EDPO window of 255 frames which we'd try to stuff in the buffer all at once.

So, I think we have some options, most of which will require a change on our end, so I'll update this issue once I have those changes made.

[l0815o]

Hello,

thanks for the answer. I already tried to increase the Tx queue size, but it did not help. The solution with the FIFO sounds promising. Let me know if I can test something for you.

[ad3154]

Hello again! I added a longwinded explanation in #5

Once that PR is merged, I will update the Arduino Library Manager to use this new version. Thanks for reporting this issue. I was able to recreate it with a different VT and make it much more stable.

[ad3154]

Update: It looks like the library manager has picked up the latest version, so if you have time @l0815o let me know if you could test this after updating to the latest version:

Thanks!

[l0815o]

Hi,

thanks for adressign this issue so soon. I got the VT example now working properly.

But I suspect that the CAN driver is still buggy. I've expanded the VT example with a TC client (from the original repo example). The program works now for about 10 minutes, but after that it got disconnected from either the VT or TC or both. The message in the serial log mentioned a timeout of the status message. So I suspect an issue with reading the CAN frames, so that sometimes some are processed to late or missed at all. Is there any way you can help me with that?

[ad3154]

Well, that's unfortunate... I am wondering if at some point it might make sense to literally just re-write the flex CAN t4 driver from scratch instead of using the tonton81 implementation, especially since we don't need filters, CANFD, or any of the other stuff layered on top of sending and receiving.

Is there any way you can help me with that?

If you have access to some kind of USB CAN adapter and could get a trace of what is happening on the bus, that could be helpful. If not, that's OK, when I get some time I can do some experimenting and see if I can reproduce the issue.

[l0815o]

@ad3154: I can do a CAN trace, but is there any chance to send it via email? The file might be quite big.

[ad3154]

I suspect GitHub will allow files larger than my email... CAN traces tend to compress pretty well, so make sure to add it to a zip, rar, or 7z archive to reduce the size. If you can't attach it here, I can provide you a link where you can upload the file