I am struggling to get STM32G474 FDCAN working, especially error handling.
Normal transmission works fine. I use TXQueue (not TXFifo) mode. I can write messages to each of the 3 message buffers. Messages are sent, I get a Transmit Occured Interrupt, I know that the message is successfully sent. All fine.
If I disconnect the bus (no peer) messages are not acknowledged by another CAN node, the message is NOT sent properly (all fine).
I am working in "auto Retransmission = disable) (DAR) mode.
When I put a message into a tx buffer, the message is sent with an error and disappears from that txbuffer
There are two registers:
FDCAN_TXBRP (transmit buffer request pending)
FXCAN_TXBCF (cancellation finished)
I can see FDCAN_TXBRP [TRP] is cleared (because the message no longer pending, because it was faulty, and no retry -> done sending, but faulty, transmit request is cleared)
I can see FDCAN_TXBCF[CF] is set (!) Transmit cancellation is finished. Obviously the hardware has canceled the faulty transmission and has set TXBCF.
I have FDCAN_ID [TCFE] (Transmit Cancellation finish interrupt enable) enabled
This interrupt never triggers despite the fact, that FDCAN_TXBCF is set
How to reproduce this:
Have anyone experienced the same? Is there no way to get an IRQ on a message which are not sent becaue of errors and automatically disappear from the TXBuffer?
At the moment I only get IRQs on successful message sent, but not on failed tx attempts.
I'm dealing with something similar (issues sending under DAR mode while only device on bus; when ACKed everything is fine). I also don't see any transmit cancellation finished IRQs. Right now I'm getting those notifications via the arbitration protocol error interrupt (FDCAN_IR->PEA). If you're using a different baudrate for data than arbitration, you'll want PED.
That being said, even though I get a number of IRQs for the failure to ACK the message (as expected), I also see my system stop transmitting after between 4 and 16 messages (seems to vary). I set FDCAN_TXBAR, but nothing happens after that. So while my suggestion might get you a little further, it also might just give you another roadblock. :\
Of course, this post is a month old, so maybe you've figure this out/worked around it somehow. If you are successfully up and running, I'd love to know how you fixed your issue!
Unfortunately I have not solved the the issue. I use a workaround for now. I set the system to "auto retry". Messages in the transmit mailboxes are not dropped and the system tries to send them out indefinitvely. Once the bus comes back to life, the messages in the message boxes are sent.
The downside of this: There are very old messages staying in the mailboxes. And when the bus comes back, these old messages are sent.