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.

SRIO debug problem on C6474

Hi ,

I'm using SRIO between a C6474 processor and an IDT switch. It works quite well. However I notice a behaviour that I can't explain when I use the CCS5 debugger through a XDS560v2 STM Jtag Pod.

The experiment described next has been configured to verify the flow control mechanism.

1) The start situation is the case in which the C6474 is writing continuously the same DirectIO message (size: 264 bytes) toward an endpoint non connected to the switch. After several writes (that fill intermediate buffers), the switch sends retry messages to the C6474. The completion status read in the LSU is then CSL_SRIO_UNAVAILABLE_OUTBOUND_CR. Counters have been implemented in the code to verify that this is the only status returned by the LSU after the first write.  This situation is normal.

2) Using the same configuration and the same code as in 1), after the program has run several seconds, I just stop it with the debug view of CCC5. The last LSU status that has been read is CSL_SRIO_UNAVAILABLE_OUTBOUND_CR. But when the program is continued, the LSU status, after the next write, is CSL_SRIO_TRANS_NO_ERR. There is no reason for this status because no endpoints receives the messages: the status should have been CSL_SRIO_UNAVAILABLE_OUTBOUND_CR.

The FREE bit in the PCR register is set, meaning that the SRIO peripheral ignores the emulation suspend signal.

I tried several debug configurations which led to the same situation.

This is annoying because the debug behaviour is different than the operational one. Has somebody an explanation, and a solution to solve this problem?

Thanks

JP

 

 

 

  • Hi JP,

    A couple things to mention.  If you are sending NWRITE, which it appears you are since you are not getting Timeout completion codes, then the CSL_SRIO_TRANS_NO_ERR is given as soon as the packet is moved from the logical layer to physical layer.  It doesn't mean that the packet landed in the target device, in your case this doesn't even exist.  Having said that, it doesn't explain the situation you are seeing.  If there is no room in the TX buffers, even after the debug session, you would see the same completion code, unless either you increased the priority of the packet transfer from what you had previously been sending, or a packet is being dropped somewhere in the complete buffered pathe.  The only way the DSP would drop a TX packet is the following, which doesn't seem to be the case:

    The TX side can drop a packet if DROP_EN (bit 2 of SP(n)_CTL) is set, depending on the status of STOP_ON_PORT_FAILED_ENC_EN (bit 3 of SP(n)_CTL) and ERROR_RATE_FAILED_THRES (bits 31:24 of SP(n)_ERR_THRESH).

    Is there a time-to-live feature in the switch that may be dropping packets after a certain time period? 

    Regards,

    Travis

  • Hi JP,

    I have found that you have made the C6474  visit IDT switch quite well. I'm using the C6455 whose SRIO is similar as C6747's  to visit the IDT switch CPS-1432 now, however, I have a problem. So, I'm pleased to listen your suggestions.

    Can C6455 send Maintenance Read operation to SWITCH for the value of CAR by means of DIO. If it is possible, how can I configure the LSU0~LSU5 registers, especially  the DESID, RapidIO Address, Hop Count and so on.

    I have tried to do this, I configure the DESID= 0xFF, RapidIO Address = 0x00, Hop Count=0, Byte_Count = 4, But the try is failed, and the LSU6 = 0x6, which means a error:"  Transaction complete, non-posted response packet (type 8 and 13) contained ERRORstatus, or response payload length was in error".

    Thanks for wasting your time seeing my question, I's my pleasure for your answers.

    Barnett

  • Hi Barnett,

    On my point of view, the values you gave for DETSID, RapidIO Address, Hop Count and byte_count are ok. Is the output port specified in the LSU correct ?

    Did you verifiy the port status on DSP and on the switch, before and after the transaction (after port initialization)? These status can give useful information.

    Regards

    JP

  • Please provide the LSU register values that you are writing.  You can definitely send a type 8 maintenance packet from the C6455.  Are you doing a read or write?  If you do, the address should be equal to the RapidIO register Offset you are trying to access.  For example, 0x00 would access the RIO_DEV_ID.  If you use a DIO packet like NWRITE/NREAD, you would have to use the full DSP memory map address, i.e. 0x02D01000 for the same register. If the DSP is directly connected to the switch, then you have correctly configured Hopcount, and DESTID is a don't care.

    Regards,

    Travis