-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VT example does not work properly #4
Comments
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.
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. |
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. |
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. |
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! |
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? |
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.
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. |
@ad3154: I can do a CAN trace, but is there any chance to send it via email? The file might be quite big. |
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 |
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.
The text was updated successfully, but these errors were encountered: