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.

RTOS/TMS320C6748: SPI In Slave Mode, GIO Read-Blocking

Part Number: TMS320C6748

Tool/software: TI-RTOS

Hi All,

I Use a TMS320C6748 Custom Board,

Spi0 is configured in slave mode 4pin with CS in interrupt mode, the SPI driver is based on pspdrivers_01_30_01.

I try calling GIO_Read from within my "CommRX_TASK" seems that GIO Read is Blocking the hole system(CommRX_TASK is forever running),

lower priority  tasks are not called till the master is sending some data.

isn't GIO read supposed to block and pend on a semaphore and release the system to handle some low priority  tasks ?

 can any one propose a reason in which GIO Read is Blocking other threads ?

Alex.

  • Hi,

    I've notified the RTOS team. They will post their feedback directly here.

    Please share which TI-RTOS SDK version are you using?

    Best Regards,
    Yordan
  • I am Using DSP/BIOS version5.41.13.42
  • Hi Alex,

    TI considers DSP/BIOS to be legacy software so it is no longer being maintained or supported on these forums. For new development, we recommend upgrading to Processor SDK.

    I'm not familiar with the PSP drivers, but to attempt to answer your question, yes, GIO read should be blocking. This can be seen in the GIO header file "gio.h," snippet below.

    /*
     *  ======== GIO_read ========
     *  Synchronous read command.  GIO_read() returns 'IOM_COMPLETE' when I/O
     *  is complete. GIO_read() returns 'IOM_ETIMEOUT' error if timeout occured
     *  before read could complete.
     */
    #define GIO_read(gioChan, bufp, psize) \
            GIO_submit(gioChan, IOM_READ, bufp, psize, NULL)
    
    
    /*
     *  ======== GIO_submit ========
     *  GIO_submit() is not typically called by the application level. Assorted
     *  macros use GIO_submit() to do the needed work.
     * 
     *  The appCallback parameter causes GIO_submit() to be synchronous or
     *  asynchronous.  If appCallback is  NULL, GIO_submit() will call the 
     *  GIO->PEND blocking function(synchronous).  Otherwise, GIO_submit()
     *  will call the callback function and argument when the I/O operation 
     *  completes(asynchronous).
     */
    extern Int GIO_submit(GIO_Handle gioChan, Uns cmd, Ptr bufp,
            size_t *psize, GIO_AppCallback *appCallback);

    You can see that GIO_read is macro'd to GIO_submit and set to always pass NULL for the AppCallback parameter, which will cause GIO_submit to pend on a semaphore. 

    As far as why it doesn't appear to be pending, I'm not sure. Looking through the driver code, I found this comment in GIO_submit(),

    /*
    * Call SEMPEND Fxn only if synchronous i/o and no error returned
    * from mdSubmitChan().
    */

    So I would check the return code of mdSubmitChan() to see if it's returning IOM_EBADIO (-1)and I would check if GIO_read is timing out. You can pull the driver code into your project so that you can step through it in CCS, this should help you debug it further. 

    I hope this helps.

  • Hi Sahin,

    Tnx for your reply,

    I have added the driver to the project (for debugging) seems that my program

    is looping endlessly i spiIntrHandler routine.

    For testing only i have disabled the interrupt and seems that GIO read is pending on a semaphore as expected.

    After some more debugging i found that the TX empty interrupt is the reason for that.

    for some reason  it is raised when enabling the SPI for transaction, see attached code below from Spi.c (pspdrivers_01_30_01 package)

    (instHandle->deviceInfo.baseAddress)->SPIGCR1 |=
    (((Uint32)CSL_SPI_SPIGCR1_ENABLE_ENABLE)
    << ((Uint32)CSL_SPI_SPIGCR1_ENABLE_SHIFT));

    the DSP is on slave mode and no transactions are made at this point(verified with scope).

    what could be the reason for that ?

    also browsing through SoiLocal.h i found the following comment :

    /**
    * \brief channel structure
    *
    * There is one ChanObj per direction. This mini-driver must be
    * opened for input and output separately.
    */

    This is how i have created the Chanel  "GIO_create("/SPI0", IOM_INOUT, &status, &chanParams, &gioAttrs); "

    is this OK? or should it actually be created separately in the following way:

    GIO_create("/SPI0", IOM_OUTPUT, ......)

    GIO_create("/SPI0", IOM_INPUT, .....)

    and could that be the reason for what i'am experiencing ? 

    Alex.

     

     

     

  • Discussion continued here: e2e.ti.com/.../695701
    Closing this thread.