dakejahl opened a new pull request, #19970:
URL: https://github.com/apache/nuttx/pull/19970
## Summary
Three defects in the i.MX RT FlexCAN transmit path, all found while chasing
an
error-passive storm on an ARK FMU-v6XRT.
**`imxrt_txtimeout_work()` aborts the wrong mailboxes.** It aborts mailbox
`RXMBCOUNT + mbi` while the deadline it consulted belongs to `RXMBCOUNT + 1
+ mbi`,
so every abort lands one mailbox low; `mbi == 0` writes `CAN_TXMB_ABORT`
into the
buffer reserved for the ERR005829 workaround and the highest TX mailbox is
never
aborted at all. Its expiry test is `now.tv_sec > d.tv_sec || now.tv_usec >
d.tv_usec`, which declares any deadline crossing a second boundary expired,
and the
`now` it compares against is a `struct timespec` cast to a `struct timeval`.
The
walk runs to `TXMBCOUNT`, which counts the reserved mailbox too, so the last
iteration addresses one mailbox past the ring and `mb_address[]` one past
its end —
in bounds today only because `txmb[]` is never written that far. And
`imxrt_txdone()` cancels the watchdog but leaves `txmb[].deadline` set, so a
retired
mailbox looks expired forever and the next expiry on any other mailbox aborts
whatever frame has since been loaded there.
Since `imxrt_txmb_next()` only hands out a mailbox above every pending one, a
mailbox left in `DATAORREMOTE` also pins the allocator at `TOTALMBCOUNT` and
transmit never recovers.
**`imxrt_transmit()` stores the deadline before it knows the frame is going
out.**
The early return for an already-expired deadline then leaves that deadline
on a
mailbox holding no frame, and the next watchdog expiry counts a transmit
timeout
that did not happen and aborts a mailbox the allocator may since have handed
to a
live frame.
**`MCR[MAXMB]` is OR-ed in rather than assigned.** MAXMB resets to 0x0f, so
the OR
can only raise it: every configuration with fewer than 16 mailboxes runs with
MAXMB = 15 and FlexCAN arbitrates over mailboxes the driver never
initialised —
with the classic payload layout MB14 and MB15 hold power-on contents, and
with a
64-byte CAN FD layout they are past the end of the mailbox RAM region.
`s32k1xx_flexcan.c` already carries this fix; the same two lines go here.
The same `timeval` cast, the same OR-ed expiry test and the same unwritten
deadline
are in `kinetis_flexcan.c`, `s32k1xx_flexcan.c` and `s32k3xx_flexcan.c`, and
the
MAXMB one in kinetis and s32k3xx. Those drivers index `priv->tx[mbi]`
directly, so
the mailbox off-by-one is imxrt's alone. Left untouched here because there
is no
hardware to test them on — happy to extend the PR if a maintainer prefers.
## Impact
Is new feature added? NO
Is existing feature changed? YES, a transmit deadline now expires when it is
actually due and aborts the mailbox that owns it.
Impact on user? YES, SocketCAN on i.MX RT no longer loses the interface to
one
expired frame. No API change.
Impact on build? NO
Impact on hardware? YES, i.MX RT boards using SocketCAN.
Impact on documentation? NO
Impact on security? NO
Impact on compatibility? NO
## Testing
ARK FMU-v6XRT (i.MX RT1176), `ark_fmu-v6xrt_default`, arm-none-eabi-gcc
13.2.1.
Two 1 Mbit/s DroneCAN buses with a GNSS node on each, driven by the PX4
uavcan
driver. ECR, ESR1 and MCR read over SWD without halting the core.
TX timeout fix, one bus at 736 offered frames/s (9% utilisation):
before: 0 frames/s transmitted, ECR[TXERRCNT] pinned at 128,
ESR1[FLTCONF] error passive, still dead after a reboot
after: 734 frames/s, 0.1% loss, TXERRCNT 0, error active
MAXMB fix, `MCR` read back on both instances:
before: 0x0063180f (MAXMB 15, 14 mailboxes configured)
after: 0x0063180d (MAXMB 13)
No regression at 8-channel ESC RawCommand to both buses at 400 Hz plus RawIMU
back — 705 offered frames/s per bus, 31% utilisation, 120 s: 0 error
episodes,
TXERRCNT 0, 0 transmit timeouts, 0.00% loss on both interfaces.
The deadline-store fix is structural; its window is too narrow to provoke
deliberately, and it is covered by the same run showing no timeouts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
