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.

6678 SRIO low-level test program

Other Parts Discussed in Thread: SYSBIOS

TI experts-

We are working on an SRIO low-level test program for a new board.  It's been difficult to build this program, I found that numerous pieces of C code had to be mixed and matched.  After a multi-day struggle, I'm down to two (2) symbols that I cannot resolve:

   ti_sysbios_family_c64p_EventCombiner_unused_F
   ti_sysbios_knl_Semaphore_post__E

These symbols result from EventCombiner_unused() defined in EventCombiner.c and Semapore_post() defined in platform_osal.c, inside a function called Osal_srioPostSem().   (Note that srio_drv.c contains a function called Srio_osalPostSem() which I assume is the same; maybe different groups of TI programmers switched up the naming at some point).

The SRIO test example I'm using is loopbackDioIsr.c which calls Srio_start(), which should allow us to verify that SRIO links are established between the 6678 and FPGA devices on our board.  Up to this point we are able to successfully call SrioDevice_init and Srio_init().  We are not using SYSBIOS yet, at this level of debug.

How can I resolve these symbols?  It looks to me like both eventually result from calling EventCombiner functions, which assume SRIO interrupts will be processed.  Possibly I can disable SRIO interrupts for the time being, for low-level test purposes?  Thanks.

-Jeff
Signalogic

  • Follow-up...

    I'm currently running the test code in evm66x_device_srio_loopback.c with CSL_SRIO_SetLoopbackMode() APIs commented out, and I'm getting port_ok on all four (4) ports. But, even if the FPGA doesn't have its SRIO logic core loaded, I still get port_ok.  Is anything else needed to ensure internal loopback is not happening?

    We're to the point of disconnecting the SRIO lines between 6678 and FPGA on the board to really make sure this is a false positive, but before we do that there must be some software reason.  Any suggestions welcome.  Thanks.

    -Jeff

  • Jeff,

    It looks like you have two different categories of questions, so this may be tough to handle.

    The symbols that need to be resolved look like SYS/BIOS symbols but you said you are not using SYS/BIOS yet. I am not sure what that means, but those symbols probably need a module that is not included from the SYS/BIOS configuration. For that issue, I would have moved this to the TI-RTOS forum to get some help from the right experts.

    But that is not the right place to send your link-status concerns, so I do not know what to do best for you.

    Regards,
    RandyP

  • Randy-

    Thanks very much.  I'll stick with link issues on this thread.  The port_ok "false positive" turned out to be due to internal line loopback being set.  I had commented out the CSL_SRIO_SetLoopbackMode() API calls in my test code excerpted from evm66x_device_srio_loopback.c, but this was not enough, even after CPU and system resets.  With CSL_SRIO_SetNormalMode() calls our test program is now correctly showing port-not-ok status when we have no far-end SRIO connection.  So one or the other must be used.

    Which APIs can be used to get error status?  Currently I have these APIs

      CSL_SRIO_IsPortFatalErrorDetected()
      CSL_SRIO_GetErrorPendingInterrupts()

    but no error results are indicated.  On this thread (http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/170264.aspx) I see suggestions for reading registers:

      ERR_STAT (mmr 0xB158)
      LM_RESP (mmr 0xB144)
      ERR_DET (mmr 0xC040)
      SP0_CTL (mmr 0xB15C)

    Are there suitable CSL_SRIO APIs for these?  Thanks.

    -Jeff

  • Follow-up...

    I found srio_test_decode.c which has print-out for numerous low-level SRIO registers, so now I can see any register as needed.

    Currently port_ok is not set for any of the 4 lanes connected to our FPGA.  Are there any error/status bits that can be used to help debug this?  Or, for physical layer issues, are we in a mode where we need a digital scope and trial and error between the two ends?

    Thanks.

    -Jeff

  • Hi Jeff,

    Check SRIO port configuration on FPGA side.

    Read the port Error and status register SPn_ERR_STAT on C6678 side.

    Please See the following posts

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/p/11735/45935.aspx#45935

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/t/262359.aspx

    Thanks,

  • Ganapathi-

    If we implement a temporary wire loopback between our 6678 and FPGA, we're able to initialize SRIO on the 6678 side.  We can see port_ok and send/receive link maintenance requests.  But we still have issues on our FPGA side.  The thread link you give has some excellent suggestions which should help us to debug this.

    Thanks.

    -Jeff
    Signalogic

  • Hi Jeff,

    Thanks for your reply. If you have any issue on DSP side means continue this thread, otherwise please close this thread.

    Thanks,

  • Ganapathi-


    Yes we can close the thread.  We had to pause while our board gets an FPGA replacement.  Then we will resume testing device-to-device connectivity.

    Thanks.

    -Jeff