STM32G474 FDCAN TX buffer cancellation finish IRQ does not trigger

[Johannes]

Hello Everyone
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:

• enable FDCAN
• use DAR (auto retransmission disable)
• use TXQUEUE mode (not TX Fifo)
• enable FDCAN_IE[TCFE]  transmit cancel finish interrupt enable
• enable FDCAN_TXBCIE transmit cancellation finished interrupt enable register for each transmit buffer
• use an open CAN-Bus (no peer) 
• try to send messages by copying them into the message buffer
• add a transmission request by setting the appropriate bit in FDCAN_TXBAR 
• observe FDCAN_TXBRP, see that the request pending bit is 1 and then switches to 0 
• observe FDCAN_TXBCF, see that transmit cancellation finish bit is set
• IRQ never triggered. 

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. 

Johannes

 

 

[joh06937]

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!

[Johannes]

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. 

 

[joh06937]

It probably doesn't help either of you, but my issues came down to the way I was using the CAN buffers. Essentially my application is fine having things being sent single-file file using a single buffer, so I was attempting to reuse the same buffer each time. I discovered that if I updated a buffer and marked it to be sent immediately after the arbitration error condition occurred, I would get into my weird state of the peripheral halting after a few errors. Once I switched to using two buffers, my issue went away.