• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 103 subscribers
  • Views 1230 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C6455: SRIO multi-segment RX transaction timeout

David Boles
Intellectual 850 points
Part Number: TMS320C6455

The CC in the RX buffer descriptor shows Error, Timeout on receiving one of the segments. This seems to happen occasionally (~20%) at startup between two processors (with a Tundra switch in between). My buffer is 664 bytes long (3 segments). SPRU976E (pg 48) indicates there is a timer involved but does not specify the register and how to set it. Also, it mentions the buffer resources are to be released. How is this done so the RX interrupt is cleared? My application gets stuck continually responding to this interrupt and starves the application of processing time. Thanks.

  • 0
    TI__Guru 65405 points
    Hi David,

    I've forwarded this to the SRIO experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Mastermind 23525 points
    The timeout counter value is described in section 2.3.2.5 of www.ti.com/.../sprugw1b.pdf. For the RXU timeout (between receiving a message segment request/sending a response until receiving the next segment request) it is the same value as the TX response timer value and controlled with the same register value.

    I didn't see a description in the User Guide, but from our internal spec...

    An Rx transaction timeout is used by all multi-segment queues, in order to not hang receive mailbox resources in the event that a message segment is lost in the fabric. This response-to-request timer controls the time-out for sending a response packet to a receiving the next request packet of a given multi-segment message. It has the same value and is analogous to the request-to-response timer discussed in the TX CPPI and LSU sections, which is defined by the 24-bit value in the Port Response Time-out CSR.

    So, you can try to set this timeout value as high as possible, but if that doesn't work, I'd simply break your 664B transfer into three individual transfers (use three descriptors) using the same TX queue so that you never run into the issue. This will reduce throughput though if that is an issue, but dealing with timeouts can be very disruptive as you mentioned.

    Regards,
    Travis
  • 0 in reply to tscheck
    Intellectual 850 points

    What is the best way to clear this condition on a multi-segment queue? Teardown?