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 transmit buffer handling in case of error conditions.

Other Parts Discussed in Thread: SYSBIOS

Hi,

I am using message passing type 11 message with the SRIO driver in PDK for 6678. The accumulator is programmed to generate interrupts for SRIO transmit packets. From the transmit ISR, the descriptor is recycled in the transmit completion interrupt subroutine and the buffer associated with it is freed back to the OSAL module. 

At some point, an error was detected in RIO_ERR_DET or RIO_ERR_RST_EVNT_ICSR register. When the application stopped sending SRIO messages, it seems the transmit descriptor are not recycled and the buffer not freed.

The transmit ISR relies on the completionQueueList of the driver to determine if there are pending descriptors. Each descriptor is recycled, and the buffer associated with it is freed. When the SRIO transmit did not complete successfully, if the completionQueueList is null, it can explain why the descriptors and buffers were not recycled.

 

So, I am checking my assumptions here:

Would the transmit completion interrupt be generated if the transmit failed? Is this how the transmit error should to be handled? I have not configured a seperate interrupt for srio errors.

Would the descriptors be be put into the completionQueueList even if the transmission fails for some reason? How else can the application retrieve the buffers? I know the driver is capable of recycling the transmit descriptors to the free queue on its own. But we are not using the driver to do so. The application needs to recycle the descriptors and need to free the buffer. So, even when the transmission fails, the application needs access to the descriptor to get to the buffer.

 

Shivang

  • SRIO UG section 3.8.8 describes how SRIO errors are routed to interrupt destinations. But I guess my question about handling descriptors and buffers still remain. The application needs to be handed back the descriptor (and thereby the buffer associated with it) somehow for it be recycled.

  • SThakkar

     

    If an error occurs with sending a type 11 message passing packet, the descriptor is placed to one of the garbage queues. There is more information in the SRIO User Guide TX Response Handling,

    "The descriptor is written to a garbage collection queue rather than being returned to the free descriptor queue. There are several garbage queue, one for each error type supported. Based on the garbage queue that the software is reading from, it will the exact error that occurred. The address of the garbage collection queue is written in the garbage collection queue number register shown in Table 3-60‘‘RIO_Garbage_Coll_QID0 Field Descriptions’’on page 3-82. A designated CPU will service the garbage collection queues."

    You can handle the error messages through the garbage queues.

     

    Elush Shirazpour

  • SThakkar

     

    What example code are you using?

     

    Elush

  • I was refering to the SRIO_LoopbackTestProject in the PDK.  In the device_srio_loopback.c, the garbage collection queue are setup using CSL_SRIO_SetTxGarbageCollectionInfo.  But I dont see where these queues are monitored and descriptors recycled.

    If I understand correctly. for polling mode, a function, say processSrioError() should be called periodically in which each garbage collection queue is checked. If the interrupt routing is setup for SRIO error handling using ERR_RST_EVNT_ICRR, processSrioError() should be linked using the EventCombiner and CpInt modules.

    Between, sometimes the emulator flags an error :

    [C66xx_0] ti.sysbios.family.c66.tci66xx.CpIntc: line 311: E_unpluggedSysInt: System Interrupt# 112 is unplugged

    [C66xx_0] xdc.runtime.Error.raise: terminating execution

    The secondary input event # 112 on CIC corresponds to RapidIO, and it maps to INTDST0. Now, I think the default value of 0 in the ERR_RST_EVNT_ICRR maybe be routing SRIO error interrupts to INTDST0, and so i get this error on the core 0 sometimes when SRIO errors occur but no function is setup to handle event #112.

     

    Coming back the point, in the processSrioError(), I should be popping descriptors from each garbage queue until it is empty, and recycle them to the transmit or receive free descriptor queue depending on whether the error was encountered during SRIO tranmission from the DSP or reception on the DSP. 

    Is this more or less what needs to happen to handle SRIO errors? Is any of this present in any example code?

    Thanks,

    Shivang

  • Type 11 transmit errors are collected in the garbage queue as you mention.  It is the application's responsibility to monitor these queues, either by setting up an interrupt on the QMSS queues (similar to any RX queue for data packets) or polling the register D of that particular queue looking for any present descriptors, and then to free the descriptors by putting them on the free queue.  So basically you are correct.

    I am a little confused on the reference to ERR_RST_EVNT_ICRR since it has nothing to do with TX errors or garbage queues.  Only the errors listed in the bit field descriptions are reflexed in this reg.

    Regards,

    Travis