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.

Reseting the SRIO Peripheral

Hi,

Having satisfied myself about how to enable the SRIO peripheral I'm now trying to reset it!

I'm not sure resetting the SRIO peripheral is important but I tried to do it and now I want to understand. I wanted to reset it so that if I restart my program in the debugger I can put the SRIO peripheral into a known state i.e. reset; I'm not sure that I have any use for this in our real application.

I've tried to follow spru976b.pdf section 2.3.10.3 Software Shutdown Details. It should be noted that I'm only doing Direct I/O in my test app at the moment so I don't think there should be any problems with the RXU and TXU queue teardowns.

I'm using an EVM6455.

The first time I run after a power cycle my test apps run and my Direct I/O transfers work. (ResetSRIOPeripheral is always called.)

If I restart the transmitting app (which is on the Mezz) it doesn't seem to work, I suspect the attempt to reset the SRIO peripheral. I think ICS7 of LSU0_ICSR is set ("Packet not sent due to unavailable outbound credit at given priority").

Should I worry about this or just give up and carry on with something more relevant to my real application?

If I should worry has anyone got any guidance about how to reset the SRIO peripheral?

See below if your interested in the code.

Thanks,

Matt

Note:

* I enable the peripheral (PERCFG0) before calling ResetSRIOPeripheral and pretty much immediately after I set GBL_EN.

* The HDPs are never non-zero in my tests.

Void TearDownTxBuffers()
{
    const Int numberOfHDPs = sizeof(srioRegisters->QUEUE_TXDMA_HDP) / sizeof(srioRegisters->QUEUE_TXDMA_HDP[0]);
    for (Int i = 0; i < numberOfHDPs; ++i)
    {
        if (srioRegisters->QUEUE_TXDMA_HDP[i] != 0x00000000U)
        {
            const Uint32 txTeardownMask = 1U << i;
            srioRegisters->TX_QUEUE_TEAR_DOWN = txTeardownMask;
            CSL_SrioBuffDesc *const txBuffDesc = reinterpret_cast<CSL_SrioBuffDesc*>(srioRegisters->QUEUE_TXDMA_HDP[i]);
            while (CSL_FEXT(txBuffDesc->opt2, SRIO_TXBUFFDESC_TEARDOWN) == CSL_SRIO_TXBUFFDESC_TEARDOWN_NOT_COMPLETE);
        }
    }
}

Void TearDownRxBuffers()
{
    const Int numberOfHDPs = sizeof(srioRegisters->QUEUE_RXDMA_HDP) / sizeof(srioRegisters->QUEUE_RXDMA_HDP[0]);
    for (Int i = 0; i < numberOfHDPs; ++i)
    {
        if (srioRegisters->QUEUE_RXDMA_HDP[i] != 0x00000000U)
        {
            const Uint32 rxTeardownMask = 1U << i;
            srioRegisters->RX_QUEUE_TEAR_DOWN = rxTeardownMask;
            CSL_SrioBuffDesc *const rxBuffDesc = reinterpret_cast<CSL_SrioBuffDesc*>(srioRegisters->QUEUE_RXDMA_HDP[i]);
            while (CSL_FEXT(rxBuffDesc->opt2, SRIO_RXBUFFDESC_TEARDOWN) == CSL_SRIO_RXBUFFDESC_TEARDOWN_NOT_COMPLETE);
        }
    }
}

// See spru616b.pdf - Software Shutdown Details
Void ResetSRIOPeripheral()
{
    while (CSL_FEXT(srioRegisters->LSU[0].LSU_REG6, SRIO_LSU_REG6_BSY) == 1);
    while (CSL_FEXT(srioRegisters->LSU[1].LSU_REG6, SRIO_LSU_REG6_BSY) == 1);
    while (CSL_FEXT(srioRegisters->LSU[2].LSU_REG6, SRIO_LSU_REG6_BSY) == 1);
    while (CSL_FEXT(srioRegisters->LSU[3].LSU_REG6, SRIO_LSU_REG6_BSY) == 1);

    TearDownTxBuffers();
    TearDownRxBuffers();

    srioRegisters->PCR
        = CSL_FMKT(SRIO_PCR_PEREN, DISABLE)
        | CSL_FMK(SRIO_PCR_SOFT, CSL_SRIO_PCR_SOFT_RESETVAL)
        | CSL_FMK(SRIO_PCR_FREE, CSL_SRIO_PCR_FREE_RESETVAL);

    // Manual says "wait 1 second".
    // I haven't checked how long this loop takes but is should be a long time
    // and I'm not expecting that there will any DMA transactions attempting to complete anyway.
    delay(1000000);

    srioRegisters->GBL_EN = CSL_FMKT(SRIO_GBL_EN_EN, DISABLE);
}

  • I noticed that the C645x/7x DIO library also tries to reset (aka release) the SRIO peripheral in RIO_release and RIO_setPortConfig, so someone else has had the same idea as me.

    RIO_release in particular is similar to what I've done (I haven't setup any DMA) although I don't completely understand it.

    If I run my reset function (or some variation that clears GBL_EN) and then reload/restart my application I end up in UTL_halt and I don't know how to figure out why!

     

  • Hi Matt

    Where did you get our DIO library from? I'm working on the C6474. It didn't come with the EVM. I found the a lib here ( https://gforge.ti.com/gf/project/ ), but cant find an official download location. I was thinking it would in the update advisor location where the MQT suff is and where I got DVSDK packages when I worked on the Davinci DM648.

    Cheers

    Eddie

  • Eddie said:
    Where did you get our DIO library from?

    I think I got it from the same place as you although I can't remember how I found it now.

    I've got a svn checkout that thinks its repo is here https://gforge.ti.com/svn/sriodirectiolib.

    I've haven't really looked in to the Direct I/O Lib yet, let me know if you find anything useful!

    Eddie said:
    I'm working on the C6474.

    People around here keep talking about using the C6474 but at the moment we haven't got the single core of the C6455 doing anything!

    Eddie said:
    I was thinking it would in the update advisor location where the MQT suff is and where I got DVSDK packages when I worked on the Davinci DM648.

    It didn't occur to me that it would be in Update Advisor! The software support for the C6455 is a bit ad hoc and I would assume that it's the same for C6474.

    I've got a list of links to various download pages that I check manually.

    HTH,

    Matt

  • Hi Matt

    I got mine from the same gforge.ti.com repo.

    Thats funny, I've got a list too. I can't believe how many different places there are to store packages, etc. TI needs to ochestrate this better.

    I'm tackling the DIO today. Hopefully I'll have some good news for you.

    Cheers

  • Hi Matt

    On the C6472 I'm running the tests using ext loopback test, with a modification to make it internal loopback. See the DIO Lib cslUtils.h and in DIO_setup set

        hSrio->portConfig      = RIO_PORT_CONFIG;
        //hSrio->portMode        = RIO_PORT_MODE;  //??changed for debug test.
        hSrio->portMode        = RIO_PORT_MODE_LOOPBACK;

    It works well and is nice for verifying the code.

    But one thing I noticed, if you use HALF or QUARTER rate, I get the dreaded "unavailable outbound credit"

            hSrio->portRate[0]     = CSL_SRIO_SERDES_RATE_FULL;
            //hSrio->portRate[0]     = CSL_SRIO_SERDES_RATE_HALF;
            //hSrio->portRate[0]     = CSL_SRIO_SERDES_RATE_QUARTER;

    I'm thinking there must be something else that must be changed.

    Its rare that I get an interface to work at a high speed and then not at a lower speed!

    Cheers

  • Update

    I found that by only changing the DIO portRate parameter (or "Rate" as its named in sprue13h - C6472 SRIO users guide), I was setting the port into a unknown state. You have to follow Table 8 p31 settings. In my case, because I have 125 MHz RIOCLK, I cannot use the CSL_SRIO_SERDES_RATE_QUARTER. If I want to get 1.25 Gbps, I have to use CSL_SRIO_SERDES_RATE_HALF and change MPY to CSL_SRIO_SERDES_PLL_MPLY_BY_6.

    Hence QUARTER is not quarter rate, HALF is quarter rate. Makes sense doesn't it (doh!)

    My bad for assuming it was that easy.

    Cheers