This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280039: FSI-RX CRC and DMA behaviour

Part Number: TMS320F280039
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hi,

i would like to raise a question about specific FSI-RX module behaviour. We have a FSI fsi daisy-chain configuration, that is fully initiialized (handshaked) and transmitting frames. On any received data frame we trigger the DMA for copying 16 data-words into a buffer. There are some bit-errors on the physical line, which is why we need to confirm the behaviour of the FSI in the following cases. 

1. When the FSI-RX core detects a CRC mismatch, is the DMA trigger still executed? We do see the error irq generated and CRC-error flag is set, which is handled by the ISR. We need to know if the DMA is still supposed to copy the FSI-RX-buffer into RAM?  If yes, is it possible to prevent that behaviour?

2. The note in TRM page 3173 clearly says, that the RX-module needs to undergo a reset and resync with the transmitter in case of a CRC-mismatch. However, that specific condition is not mentioned in chapter  31.3.3.10 (Conditions in Which the Receiver Must Undergo a Soft Reset). Does the FSI-RX require a reset on CRC-error?

3. Is the CRC-calcuation (and error irq) still executed, when RX-UDATA-filtering is active and a non-matching (different UDATA) frame is received?  

Thanks for answering in advance.

Best regards,

Felix

  • Hi Felix,

    I am reviewing this thread. I will get back to you shortly!

    Thanks,
    Susmitha

  • Thank you. Do you have any update?

  • Hi Felix,

    Are you using daisy chain example from C2000ware?

    Thanks,
    Susmitha

  • Hi,

    it is not not the daisy-chain example. We are implementing our own application, based on the FSI. Without the bit-errors that is working fine, but we need to know how the FSI-RX behaves in the cases mentioned.

    Felix

  • Hi Felix,

    1. When the FSI-RX core detects a CRC mismatch, is the DMA trigger still executed? We do see the error irq generated and CRC-error flag is set, which is handled by the ISR. We need to know if the DMA is still supposed to copy the FSI-RX-buffer into RAM?  If yes, is it possible to prevent that behaviour?

    Yes, DMA will still be triggered even if there’s a CRC error in the received data frame, provided the frame has the correct structure (i.e., the proper number of data words and end-of-frame (EOF) marker).
    • The FSI hardware does not block the DMA trigger automatically on CRC mismatch — the DMA is linked to a frame reception event, not its integrity.
    • This is why the error IRQ (FSIRX_EVT_CRC_ERR) is provided — your ISR needs to use this to check the CRC error flag and invalidate or discard the DMA-copied buffer contents in software.

    Workaround/Prevention:
    You cannot directly block the DMA trigger in hardware on CRC failure. However:
    • In your ISR, immediately check for the CRC error flag before using the DMA’d buffer.

    Section 31.3.3.10 is more authoritative for when a soft reset is required — typically, only after EOF misalignment, framing errors, or hardware state corruption.
    • A single CRC error does not necessarily imply a synchronization failure between RX and TX. You should only perform a reset if you also detect framing errors or persistent CRC faults that indicate the RX module may be desynced.

    No, CRC is not calculated and no error IRQ is triggered for non-matching UDATA frames if RX-UDATA filtering is enabled.
    • The RX hardware will simply ignore and discard any incoming frames with a UDATA tag that doesn’t match the programmed filter.

    Thanks,
    Susmitha

  • Thank you very much for the detailed response. That helps us understanding the system better.