LPC55xx CAN TX Fifo usage in fsl_mcan

[MartinHo]

Hi,

I would like to use the TX fifo function of the CAN (FD) controller on the LPC55xx.

Unfortunately i didn't fine any example for this.

A fast check of the driver code seems to confirm that the driver fsl_mcan don't support the use if the TX fifo. While it possible to configure the controller via the Config tool in MCUXpresso, the fifo is handle as a single TX Buffer.

Has somebody an example how to use the TX fifo on this controller?

best regards

Martin

[RaRo]

Hello @MartinHo,

I hope you are doing well,

Please check the LPC550x, 1x, or 3x SDK MCAN examples.

Please make sure that txBuffer.mode equals 0 before initializing the MCAN Tx buffer (refer to the main function of the examples)

This will set the Tx FIFO operation mode in the TXBC register:

Additionally, you can modify the dedicated Tx Buffers; refer to txBuffer.dedicatedSize member of Tx Buffer config. structure.

Please let us know, if there is anything else where we could help you.

Best regards, Raul.

[MartinHo]

Hi Raul,

Thanks for Your answer, the *.mode value is set automaticaly by the configuration tool (I have check and its set to kMCAN_txFifo = 0).

But my problem was that when You decide to configure, for example, 32 TX FIFO Buffers, the driver will only use 1 element of the FIFO, because the only possibility to write a new TX Message is when the state machine inside the driver is in kMCAN_StateIdle (for a given buffer Index), an this is set only when MCAN_TransferAbortSend is called. But this function is called only when the kMCAN_TxTransmitCompleteFlag is set in the IR register, so I can only wite a new TX Message once the prior message was transmitted.

Newer mind, I have decided to use 32 single TX Buffers and handle the filling of the buffers by my self. This works ok because 32 different buffer index's are used.

best regards

Martin

[Peter-M2PRO]

Through pain and suffering I've found that the MCAN driver in FSL v2.1.4 does not support Tx FiFo operation, despite the API suggesting it does.

Deep down in the comments of the MCAN_TransferHandleIRQ implementation on lines 1632 through 1652 I've found the following:

        else
        {
            /* Handle the interrupt flag unsupported in current version of MCAN driver.
             * User can get these unsupported interrupt flags by callback function,
             * we can clear directly in the handler to prevent endless loop.
             */
            result = valueIR;
            result &= ~((uint32_t)kMCAN_ErrorWarningIntFlag | (uint32_t)kMCAN_ErrorPassiveIntFlag |
                        (uint32_t)kMCAN_BusOffIntFlag | (uint32_t)kMCAN_TxTransmitCompleteFlag |
                        (uint32_t)kMCAN_RxFifo0NewFlag | (uint32_t)kMCAN_RxFifo0LostFlag |
                        (uint32_t)kMCAN_RxFifo1NewFlag | (uint32_t)kMCAN_RxFifo1LostFlag);
        }

        /* Clear Error interrupt, resolved Rx FIFO, Tx Buffer IRQ and other unsupported interrupt flags. */
        MCAN_ClearStatusFlag(base, result);

        /* Calling Callback Function if has one. */
        if (handle->callback != NULL)
        {
            handle->callback(base, handle, status, result, handle->userData);
        }

As suggested in the comment, you could implement the missing interrupt handling in a callback instead.