Repository navigation
examples: acf-can: clear each frame slot before decoding into it - #221
Conversation
avtp_to_can() decodes into a caller-provided frame array and the CAN FD flag handling only ORs FDF, BRS, and ESI into frame->fd.flags, never clearing them. Both bridges reuse their frame arrays across received AVTPDUs without zeroing them, the Linux bridge through a long-lived local array and the Zephyr bridge through a static one, so a slot that once held an FD frame keeps those flag bits when a later AVTPDU reuses it for a classic frame, and the classic frame is written to the CAN interface with stale FDF, BRS, or ESI set. Zero each frame slot before decoding into it. Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #221 +/- ##
=======================================
Coverage ? 97.00%
=======================================
Files ? 59
Lines ? 6977
Branches ? 199
=======================================
Hits ? 6768
Misses ? 186
Partials ? 23 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
nayakned
left a comment
nayakned
left a comment
There was a problem hiding this comment.
Looks good. Thanks for the fix.
Glad to contribute, love the project. Also I think my other fix I had from a few months ago is already fixed upstream, just only now got the time to get around to submitting my patches, my bad. Btw, not sure how involved any of you are with Zephyr RTOS directly, but I think with our push to make robotics a "first class experience" for Zephyr users, I would love if anyone from COVESA (especially the Open1722 side) would be interested in joining one of our Zephyr Robotics WG calls as we start focusing heavily on usage of 1722, TSN, MACsec, etc in real end systems. |
2 participants
The ACF-CAN listener decode path never initializes the frame slot it decodes into. avtp_to_can() only ORs FDF, BRS and ESI into the flags, and both bridges reuse their frame arrays across received AVTPDUs, a long-lived local array on Linux and a static one on Zephyr. A slot that previously held a CAN FD frame therefore sends later classic frames to the CAN interface with stale FDF, BRS or ESI set.
My fix for it is to zero each frame slot immediately after the frame count bounds check, before decoding into it.
Tested with an MCXN-T1 with Zephyr pre-4.5 that decodes an FD frame with FDF, BRS and ESI set, then a classic frame into the same slot. On current main the classic frame carries the stale flag bits, with this change it comes back clean while the FD frame keeps its real flags.