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.

TMS320C6678: SRIO output retried error

Part Number: TMS320C6678

Hello SRIO experts,

(a bit of background : we are a team quite experienced with SRIO on C6678, having implemented it and debugged it for around 5 years, we know how to manage doorbell retries, restart transactions etc.)

Today on a running system at the lab, we have a strange issue

Most of the time the system is running perfectly.

Under very specific conditions the system blocks.
Analysis shows that a SRIO transaction with doorbell didn't work : the data was not written, the doorbell not sent

Using the TI GEL file that is very helpful to debug SRIO conditions, we looked at the initiator of the transaction

The port error status of the port 0 has the following value : 0x180002
Meaning port ok, output retry encountered, output retried

It's the first time we encounter "Output retried" (bit 19)
the doc says "Output port has received a packet-retry control symbol and can not make forward
progress. This bit is set when bit 18 is set and is cleared when a packet-accepted or a
packet-not-accepted control symbol is received (read-only)."

Bit 18 is "Output retry-stopped".
According to the doc (and to the SRIO spec) it should be set along with bit 19. --> this is strange and not conform to the spec

Anyway does anyone why such an error can occur ? and how to recover from it ?

Best regards
Clement

  • Investigations continue and here's the latest info

    I didn't precise a few things. The error occurs on a DSP that tries to send data to another DSP through a SRIO switch.
    DirectIO is used. it is a multicast write.

    We looked at the SRIO port connected to the DSP port. We see an "input retry-stopped" error and "ack id misalignement problem"

    By looking at the local ack id status register of the switch port, we see :

    - inbound ack id = 0x6
    - outstanding ack id = 0x1B
    - outbound ack id = 0x1B

    on the DSP side we see :

    - inbound ack id = 0x1A
    - outstanding ack id = 0x01
    - outbound ack id = 0x02

    As far as I understand it : the DSP core sent a SRIO nwrite transaction. It is expecting an acknowledgement. so it stocked the expected ack id in "inbound ack id = 0x1A"

    The SRIO port was apparently unable to sent an acknowledge (or the wrong one ?) and then it's not clear to me if it has sent an ack with 0x1B or that the next time it will send an ack id of 0x1B.

    Does anyone know how the ack ids work and the relation with the register "local ack id status"

    also the issue has been reproduced with another board

    regards

  • Hi Clement,

    Did you already have the attached 'Software Assisted Error recovery' in your application?

    4075.Keystone Software Assisted Error recovery_addendum.pdf

    The error recovery mainly deals with OUTPUT ERROR-STOPPED and/or INPUT ERROR-STOPPED, as well as misaligned ACKID.

    Regards,

    Garrett

  • Hi

    Yes we implemented it at initialisation after initialising the peripheral

    we have noticed other errors in the switch, related to a connection to an FPGA so we are looking at the FPGA side.

    maybe what we see is a consequence of problems higher up the chain

    regards