TX_COMPLETE interrupt is not triggered

[Simsys]

I had some difficulties getting the TX_COOMPLETE interrupt to work. Here is an excerpt from my test code.

can.enable_interrupt_line(InterruptLine::_0, true);
can.enable_interrupts(Interrupts::RX_FIFO0_NEW_MSG | Interrupts::TX_COMPLETE);
unsafe {
    cp.NVIC.set_priority(interrupt::FDCAN1_IT0, 1);
    NVIC::unmask(interrupt::FDCAN1_IT0);
}

If I now send and receive CAN bus datagrams, RX_FIFO0_NEW_MSG is triggered, but not TX_COMPLETE.

After the following lines have been inserted, the TX_COMPLETE Intterupt is triggered on the STM32H743 system, as expected. However, this is certainly not the intended path.

unsafe {
    // FDCAN_TXBTIE Tx buffer transmission interrupt enable register
    core::ptr::write_volatile(0x4000a0e0 as *mut u32, 0xffff_ffff);
}

Have I overlooked something, or is there a mistake here?

[projectgus]

I think you're right, the transmission complete (TXBTIE) and transmission abort (TXBCIE) register bits aren't being set so TxComplete and TxCancel interrupts are never generated.

I have a WIP commit to add an API for this here: projectgus@7a67d6d

This works on STM32G4 but the STM32H7 register interface is more complex as the TX queue sizes are configurable. I haven't had time to find the code in FDCAN that splits this up yet.

However, I actually wonder if it's worth having an API for this, compared to just setting all of the register bits by default. It's a relatively niche use case to want Tx interrupts but only for some mailboxes.

[Simsys]

For me, it would be completely ok to set all the bits. In any case, I ask myself at various points whether it makes sense or is even worth striving for to map all hardware options. The APIs then become more complex and harder to keep track of.

But I can't speak for the general public