STM32G491 FDCAN TxBufferCompleteCallback never called

[unicyclebloke]

I have set up the FDCAN and confirmed that sending single messages works. However, I cannot get the FIFO to work at all - if I queue two messages at the same time, only the first appears on the wire. It is fine if I add a 1ms delay before sending the second message. I guess this works because the first message is long gone rather than still active. Rather than dig into the HAL code, I created an external queue to feed messages in one at a time. The idea is to call 

HAL_FDCAN_AddMessageToTxFifoQ() to set up the next message when I get a TX interrupt.

I can receive the FDCAN_IT_TX_FIFO_EMPTY interrupt which calls TxFifoEmptyCallback(). Calling HAL_FDCAN_AddMessageToTxFifoQ() from here has the same problem - the second message is not sent.

I have also tried to receive the FDCAN_IT_TX_COMPLETE interrupt but have been completely unable to get the implementation to call TxBufferCompleteCallback(). My interrupt activation code is 

    if (HAL_FDCAN_ActivateNotification(&m_hfdcan,

        FDCAN_IT_RX_FIFO0_NEW_MESSAGE | FDCAN_IT_TX_FIFO_EMPTY | FDCAN_IT_TX_COMPLETE,

        FDCAN_TX_BUFFER0 | FDCAN_TX_BUFFER1 | FDCAN_TX_BUFFER2) != HAL_OK) ...

Is HAL broken? I have seen several queries similar to mine but no solutions.

[unicyclebloke]

I have managed to get consecutive messages to work by inserting a delay in TxFifoEmptyCallback() of about 50us. This seems rather arbitrary and unsatisfactory. My guess is that the TX complete interrupt is the right place to do this, but I am still not able to make it happen.

[unicyclebloke · Accepted solution]

I resolved this by changing the mode to External Loopback. I now get the TX complete interrupt and it behaves exactly as expected. I currently have no other device on the bus, so I guess that was a problem. It remains to be seen how this works for reception.