TXBHCI is triggered on wrong state transitions
Scenario:
a) wrongly configured bitrate for can5 (can4 active)
- for 50x lower bitrate (500k vs 10k) it does happen
- for 2x higher bitrate (500k vs 1m) it does not happen
b) can5 is alone on the bus
-> send one frame
Observed:
[ 1472.532024] ctucanfd 43c70000.CTU_CAN_FD can5: ctucan_start_xmit: using TXB#0
[ 1472.544982] ctucanfd 43c70000.CTU_CAN_FD can5: TXBHCI
[ 1472.556189] ctucanfd 43c70000.CTU_CAN_FD can5: TXI: TXB#0: status 0x2
[ 1472.562603] ctucanfd 43c70000.CTU_CAN_FD can5: BUG: TXB not in a finished state!
[...]
[ 1472.637677] ctucanfd 43c70000.CTU_CAN_FD can5: TXBHCI
[ 1472.648884] ctucanfd 43c70000.CTU_CAN_FD can5: TXI: TXB#0: status 0x1
[ 1472.655298] ctucanfd 43c70000.CTU_CAN_FD can5: BUG: TXB not in a finished state!
[...]
[ 1472.668772] ctucanfd 43c70000.CTU_CAN_FD can5: ctucan_err_interrupt: ISR = 0x00000804
[ 1472.676588] ctucanfd 43c70000.CTU_CAN_FD can5: error_warning
[...]
[ 1472.719369] ctucanfd 43c70000.CTU_CAN_FD can5: ctucan_err_interrupt: ISR = 0x00000810
[ 1472.727184] ctucanfd 43c70000.CTU_CAN_FD can5: epi: state = 2
[ 1472.733082] ctucanfd 43c70000.CTU_CAN_FD can5: error_passive
In other words, TXBHCI is triggered when it shouldn't. It is independent of era/erw/erp state. Untested in bus-off state.
TODO:
- how is TXBHCI generated?
- what happens with TXB status when an error is detected?
- watch it by zlogan, look into RTL