• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 801 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.

Original question:

TMS320F280049: FSI interface clarification

AM2634: FSI Comms Error clarification

George Haigh
Prodigy 10 points
Part Number: AM2634


I would like some further information about the FSI error detection. I'm referring to spruj17d TRM, and I have seen a similar question here https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/849424/tms320f280049-fsi-interface-clarification

As the CRC protect the User Data and Data Words, and isn't present in a Ping Frame, I would like to know what error detection is possible for a Ping Frame. Similar for the 7.4.8.2.2.2 Receive Interrupts section.

In spruj17d section "7.4.8.3.3.10 Conditions in Which the Receiver Must Undergo a Soft Reset", error conditions are defined, but not the detail of the detection mechanism. 

My questions:

Does "Frame type error" detect if the received Frame Type field does not match the allowable values, or does it also check if the Frame Type received does not match with the rest of the frame content? would this error flag if a Ping frame type was received and there was User Data, or Data Words present in the frame?

I can see there is a "End of Frame error". Section 7.4.8.2.2.2 states that an invalid bit pattern has been received, so I presume that this checks the the EOF field is 0110.

However there is not an equivalent for Start of Frame. If there was corruption in Start of Frame, or Preamble, would no frame be detected, and / or would an Error Interrupt be received? 

If there was corruption in Post Amble, would no frame be detected, and / or would an Error Interrupt be received? (Frame Watchdog Timeout (FRAME_WD_TO)?)

Thanks

George

  • 0
    TI__Intellectual 1110 points

    Hi George,
    I am looking into this and will get back to you at the earliest.

    Thanks and Regards,
    Aswathi

  • 0 in reply to Aswathi R
    Prodigy 10 points

    Thank you very much.
    My question can probably be simplified to:
    If there was corruption in Preamble, SOF, Frame Type EOF or Post Amble, would an error be raised by the FSI module?

    And does the FSI module check that the Frame Type field matches the Frame Format?

    Thank you again

  • 0 in reply to George Haigh
    TI__Intellectual 1110 points

    Hi George, hope this answers your questions.

    George Haigh said:
    If there was corruption in Preamble, SOF, Frame Type EOF or Post Amble, would an error be raised by the FSI module?

    Pre-amble and post-amble are actually 4 clock edges. It is not any valid pattern or data. After preamble 4 clock edges, the receiver is flushed and ready to receive new frames. After the post amble 4 clock edges, the data and clock lines come back to inactive state. 


    The valid patterns for SOF and EOF are: 1001 for SOF and 0110 for EOF. If an incorrect EOF pattern is received, the receiver goes into soft reset state after raising an EOF error. In case of invalid SOF, there is no error raised as such, it will just keep waiting for a valid pattern to start receiving.


    George Haigh said:
    And does the FSI module check that the Frame Type field matches the Frame Format?

    Yes it does. If the type is 0000 (ping) then the receiver automatically expects only 16 bits, which is the size of a ping frame. This is same for all frame types except DATA_N_WORD.
    In case of DATA_N_WORD frame, the N_WORDS field of TX_FRAME_CTRL[7:4] register should be set to one less than the number of words to be transmitted. Similarly you will be configuring RX_OPER_CTRL.N_WORDS register field also to be of the same value.

     

    In case of an invalid frame type (value not in table 7-135 of TRM):

    (From section 7.4.8.3.2.3 of TRM).


    Regards,
    Aswathi

  • 0 in reply to Aswathi R
    Prodigy 10 points

    Thanks Aswathi for your response, really appreciated.

    Can I just clarify:

    1. Regarding Pre and Post Amble

    "Pre-amble and post-amble are actually 4 clock edges. It is not any valid pattern or data. After preamble 4 clock edges, the receiver is flushed and ready to receive new frames. After the post amble 4 clock edges, the data and clock lines come back to inactive state. "

    In the scenario below, if a ping frame was received, but the Post Amble was corrupted (such as the clock was faulty, or the data was corrupt), given that the Preamble has the same pattern as the Postamble, could the Preamble of a subsequent frame result in the initial frame (with the corrupt Postamble) being received?  See the diagram below. Red Post Amble on the first frame indicates corrupt data,

    Q: Would the receiver flag this as an error? 

    2. Regarding the Frame Type. regarding the answer your provided I have a query:

    "George Haigh said:
    And does the FSI module check that the Frame Type field matches the Frame Format?
    Yes it does. If the type is 0000 (ping) then the receiver automatically expects only 16 bits, which is the size of a ping frame. This is same for all frame types except DATA_N_WORD."

    Q: In this instance (where the frame type an format / length, would that be flagged using the "Frame Type Error (TYPE_ERR)"?

    Best regards

    George

  • 0 in reply to George Haigh
    TI__Intellectual 1110 points

    Hi George,

    In case of a faulty clock, the receiver goes into an undefined state and must undergo a soft reset. After the receiver has been placed into soft reset, the application must notify the other device's transmitter to begin a new synchronization phase using a ping or error frame. It is documented in section 7.4.8.3.3.10.

     

    And no this is not a frame type error. Frame type error is only raised when frame type field of the data frame has an invalid value, as I already mentioned in the previous reply.

     

    Regards,

    Aswathi

  • 0 in reply to Aswathi R
    Prodigy 10 points

    Apologies for the delay in replying, and thanks for the information.

    For Question 1: Got it thank you. 

    For question 2. In the event that the Frame Type does not match the frame format, is there an error raised? You said that the receiver will expect 16 bits if the frame type is PING, but I would like to know what is reported / how / if an error is reported if more than 16 bits are received.

    Is there a more comprehensive FSI reference than in the TRM?

    Thanks

    George

  • 0 in reply to George Haigh
    TI__Intellectual 1110 points
    George Haigh said:
    if more than 16 bits are received

    This scenario means that the receiver did not get a valid EOF pattern within the 16 bits, hence it is an EOF error. The RX_VIS_1.RX_CORE_STS bit gets set because of this. So the receiver must be reset and resynchronized. Section 7.4.8.3.3.10 "Conditions in Which the Receiver Must Undergo a Soft Reset".

    Regards
    Aswathi