• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 532 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMDSCNCD280039C: FSI TX triggered by RX while in TDM mode

Charu Fadnavis
Prodigy 10 points

Part Number: TMDSCNCD280039C

Hi,

Could you share some sample code configuring a TDM-enabled node in a daisy-chain configuration that uses the RX_TRIG_CTRL_0 with a trigger select of 1 (Data Packet Received) to trigger the transmit of an FSI packet, please?

Thanks,

Charu

  • 0
    TI__Mastermind 21245 points

    Hi Charu,

    As the App Note mentions, the 'fsi_ex_daisy_handshake_node' example showcases the TDM feature: Using the Fast Serial Interface (FSI) With Multiple Devices in an Application.

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    Prodigy 10 points

    Thank you for the response. I have further questions. Can we talk offline, please?

    Thanks,
    Charu

  • 0
    TI__Mastermind 21245 points

    Charu,

    Let's try to discuss at least the high-level questions here as it serves as a knowledge base for future users of FSI. If needed, we can have an offline discussion :) 

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    Prodigy 10 points

    Aishwarya,

    Q1:
    Setting RX_TRIG_CTRL_0 to trigger an FSI TX when a data packet is received. Given RX_TRIG_DLY is 24-bit count in SYSCLK cycles, expect to configure an up to ~140ms delay ((2^24)*1/120e6). However, seeing a 2us delay when RX_TRIG_CTRL_0 is set to 0xFFFFFF03U. Tried setting the delay to smaller values, but it doesn't appear to correctly correlate with the delay value being set.

    * 2 count delay -> 80ns delay observed. Expected ~16ns
    * 120 count delay -> 200ns delay observed. Expected ~1us.
    * 1200 count delay -> 1.5us delay observed. Expected ~10us.
    * register set to 0xFFFFFF03U -> 2.2us delay observed. Expected ~140ms.

    Measuring the delay by reviewing the CLOCK signal and measuring the length of the signal being high between transmits.

    Any suggestions as to why the timing is not as expected with RX_TRIG_DLY?

    Q2:
    RX_TRIG_CTRL_0 allows TRIG_SEL to be "Data Frame Match Occurred". Want to confirm that this is set by configuring RX_FRAME_TAG_UDATA and also maps to the DATA_TAG_MATCH interrupt.

    Thanks,

    Charu

  • 0 in reply to Charu Fadnavis
    Prodigy 10 points

    Hi Aishwarya,

    Any updates, please?

    Thanks,

    Charu

  • 0
    TI__Mastermind 21245 points

    Charu,

    Apologies for the delay. Please allow me to get back to you on Monday.

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    Prodigy 10 points

    Hi Aishwarya,

    No issues. Still seeing the issue with the delay. Looking forward to your response.

    Thanks,

    Charu

  • 0
    TI__Mastermind 21245 points

    Charu,

    Apologies for the delay, I was trying to replicate this on my setup. Please see my answer below: 

    Charu Fadnavis said:
    Any suggestions as to why the timing is not as expected with RX_TRIG_DLY?

    If I'm assuming correctly, you are measuring the FSI_TX_CLK signal and measuring how long it stays high during the actual transmission of a frame, not the internal trigger delay, so this includes the time taken to transmit TX frame, FSI TX prescalar, and frame structure. If you want to measure the delay, you can include a GPIO toggle or use the CCS Clock to measure this value specifically from RX event to TX start.

    If my assumption is incorrect, can you confirm if you are using/including the DMA in this transfer time?

    Charu Fadnavis said:
    RX_TRIG_CTRL_0 allows TRIG_SEL to be "Data Frame Match Occurred". Want to confirm that this is set by configuring RX_FRAME_TAG_UDATA and also maps to the DATA_TAG_MATCH interrupt.

    Yes, this is correct. 

    Best Regards,

    Aishwarya