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.

spiIntrHandler doesn't seem to be called in BIOS PSP

Other Parts Discussed in Thread: TMS320C6748

Hello,

I have BIOSPSP 3.00.01.00 with CCS v5.2.1.000018 and SYS/BIOS 6.33.06.46 on TMS320C6748 DSP, I was using SPI0 ands SPI1 through BIOS PSP driver which works fine, but I have a problem with CS not being raised quickly enough.  I'm using Spi_Mode_DMAINTERRUPT as you can see below. As I understand the spiIntrHandler is responsible with toggling high the CS line but it doesn't seem to be called, please see below how I have initialized the driver.

Sys/BIOS app.cfg file contains:

var dev2Params = new DEV.Params();
dev2Params.instance.name = "devSpi_0";
dev2Params.initFxn = "&userSpi0Init";
dev2Params.deviceParams = "&g_spi0Params";
dev2Params.devid = 0;
Program.global.devSpi_0 = DEV.create("/spi0", "&Spi_IOMFXNS", dev2Params);

Main.c code:

GIO_Handle m_spiHandle=NULL;

Spi_Params g_spi0Params;

void userSpi0Init()
{
    g_spi0Params = Spi_PARAMS;

    g_spi0Params.hwiNumber = 9;
    g_spi0Params.spiHWCfgData.intrLevel = FALSE;
    g_spi0Params.opMode = Spi_OpMode_DMAINTERRUPT;

    g_spi0Params.outputClkFreq = 10000000;
    g_spi0Params.loopbackEnabled = FALSE;
    g_spi0Params.edmaHandle = NULL;

    g_spi0Params.spiHWCfgData.masterOrSlave = Spi_CommMode_MASTER;
    g_spi0Params.spiHWCfgData.pinOpModes = Spi_PinOpMode_SPISCS_4PIN;

    g_spi0Params.spiHWCfgData.configDatafmt[0].charLength = 8;
    g_spi0Params.spiHWCfgData.configDatafmt[1].charLength = 16;
    g_spi0Params.spiHWCfgData.configDatafmt[0].clkHigh = TRUE ;
    g_spi0Params.spiHWCfgData.configDatafmt[0].lsbFirst = FALSE;
    g_spi0Params.spiHWCfgData.configDatafmt[0].oddParity = FALSE;
    g_spi0Params.spiHWCfgData.configDatafmt[0].parityEnable = FALSE ;
    g_spi0Params.spiHWCfgData.configDatafmt[0].phaseIn = FALSE ;
    g_spi0Params.spiHWCfgData.configDatafmt[0].waitEnable = FALSE;
    //g_spiParams.spiHWCfgData.configDatafmt[0].wdelay = 0;
    g_spi0Params.spiHWCfgData.csDefault = 0xff;


    g_spi0Params.spiHWCfgData.intrLevel = TRUE;

    EDMA3_DRV_Result edmaResult = 0;

    Error_Block eb;
    Spi_ChanParams chanParams;
    GIO_Params ioParams;

    Error_init(&eb);

    /*
    * Initialize channel attributes.
    */
    GIO_Params_init(&ioParams);

    /* initialize the stream attributes */

    chanParams.hEdma = edma3init(0, &edmaResult);
    ioParams.chanParams = &chanParams;
    //g_spi0Params.edmaHandle = chanParams.hEdma; 

    /* create SPI channel for transmission */
        m_spiHandle = GIO_create("/spi0", GIO_INOUT, &ioParams, &eb);

        if (NULL == m_spiHandle)
        {
            return 0;
        }

}

int Transfer(uint8_t cs, uint8_t *pWriteBuffer, uint8_t *pReadBuffer, uint16_t bufferLength)

{
    Spi_DataParam dataparam;
    SizeT size = 0;
    Error_Block eb;

    Error_init(&eb);

    /* clear the spi params data structure */
    memset(&dataparam, 0x00, sizeof(Spi_DataParam));

    dataparam.chipSelect = 1 << cs;
    dataparam.bufLen = bufferLength;
    dataparam.inBuffer = pReadBuffer;
    dataparam.outBuffer = pWriteBuffer;
    dataparam.flags = Spi_CSHOLD;
    dataparam.dataFormat = Spi_DataFormat_0;

    size = dataparam.bufLen;

    /* write command to FLASH */

    int32_t error = GIO_submit(m_spiHandle, IOM_WRITE, &dataparam, &size, NULL);

    if ((error != 0) && (size != 0))
    {
        System_printf("SPI0 Write: Data Write Failed: %d\n", error);
        return 0;
    }
    return size;
}

Does it matter which hwiNumber needs to be selected? My event combiner is using 8, 9, 10, 11 interrupts. Does it matter if intrLevel is true or false? According to Spi example, edmaHandle is NULL in driver initialization, is it changed to edma3init result when channel is created?

Most important question, hope someone can answer, is it normal that spiIntrHandler is not called in Spi.c?

Thank you in advance,

David.

  • I discovered it is called only when opMode is Spi_mode_INTERRUPT and in DMA a different handler is called. Doesn't explain though why CS is raised after 300us on a 300MHz processor.

  • Hi David,

    David Luca said:
    I discovered it is called only when opMode is Spi_mode_INTERRUPT and in DMA a different handler is called

    Absolutely.

    David Luca said:
    Doesn't explain though why CS is raised after 300us

    How did you calculate this? I mean, Is it the time taken for CS going low after GIO_write(..) is called? Or for the complete transaction?

    In the 'Spi_edma.c' file, we write to "*spiDat1Cfg" which would assert the CS HOLD line(CS going low), and then the EDMA configuration is done for Rx and Tx events. After EDMA configuration, the EDMA transfer is enabled for both Rx and Tx. Then, when the transfer is complete the CS is raised. 

    Best Regards,

    Raghavendra

  • Hi Raghavendra,

    Thank you for explanation, actually for one particular transfer I need to transfer one byte command via SPI but the whole transaction was seen on the scope after GIO_write was called is 680us from CS low to CS high, the SPI clock is 10MHz, looking at the clock line the data transfer starts after about 300us after CS goes low  and there are aprox. 300us more until the CS is raised. For the chip we use, this is unacceptable as it requires the CS to be raised after maximum 47us. Is there a way to optimize further when CS is raised?

    Best regards,

    David.


  • David,

    Please refer to the following post(SPI related) - http://e2e.ti.com/support/embedded/bios/f/355/p/99324/352913.aspx#352913

    In the above post, the PSP version is different, but still holds good for this version of PSP too. Also, look into the difference report attached and try. This might be helpful for you.

    Otherwise, all the settings done in the driver are appropriate as per the required configurations. I do not think there is anything additional that would add considerable delay in the driver.

    Hope this helps..

    Best Regards,

    Raghavendra