CCS/CC2650MODA: Interrupt triggering CS SPI CC2650 Ti-RTOS

Gennadiy Pavlov

Part Number: CC2650MODA
Other Parts Discussed in Thread: CC2650

Tool/software: Code Composer Studio

Hello.

In my project, I receive data on bluetooth and send it to the master via the SPI interface.
How to start an interrupt to recieve/transmit data from the master.

SPI: Slave, POL0, PHA0;

Board: CC2650 LaunchPad, CC2650MODA

If you use PIN_registerIntCb(SPIHandle, &SPICallbackFxn)

There is a delay of 11 characters at a speed of 1MHz

PIN_Config SPIPinTable[] = {
    IOID_11 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_NEGEDGE,
    PIN_TERMINATE
}; 

SPIHandle = PIN_open(&SPIPinState, SPIPinTable);

static void SPICallbackFxn(PIN_Handle handle, PIN_Id pinId)
{
    bool transferOK = false;
    if (!transmitting)
    {
        tx_string[0]='T'; tx_string[1]='e'; tx_string[2]='s'; tx_string[3]='t'; tx_string[4]='s'; tx_string[5]='t'; tx_string[6]='r';
        //*******************************
        SPI_trans.count = (uint8_t) strlen(tx_string);           //
        SPI_trans.txBuf = tx_string;                             //
        SPI_trans.rxBuf = rx_string;                             //
        transferOK = SPI_transfer(SPI_connetction, &SPI_trans);
    }
}

over 8 years ago

0 IUsedToBeARealPerson (M-W) over 8 years ago

TI__Guru 58425 points

Hi,

There will be some delay from the pin interrupt to when the SPI is ready to receive, 11 characters seems a bit high tho.

What is the full length of the tx_string and rx_string buffers? Is you r project battery driven, i.e. do you have any power constrains?

0 Gennadiy Pavlov over 8 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 170 points

Size of each buffer is 40 bytes.

I changed the wording:

"I have a project in the Code Composer Studio for CC2650. Project is battery driven and have power constarins.

CC2650 is SPI Slave device. Delay between start of recieve first byte from master and start PIN interrupt is very large. Picture of master SPI is in attachment.

How to do it right?"

0 IUsedToBeARealPerson (M-W) over 8 years ago in reply to Gennadiy Pavlov

TI__Guru 58425 points

Is "Interrupt CS" the IOID_11 line?

Looking at your code (assuming this is the slave side), you will not start a transfer until the interrupt appear (and I guess IOID_11 is connected to the master generating the interrupt). Looking at the logic trace you posted, the interrupt seem to happen after the master actually starts transferring data, I would have expected this to appear before the master begins the transfer.

0 Gennadiy Pavlov over 8 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 170 points

"Interrupt CS" is pin(IOID_15 ), it toggle when called SPICallbackFxn.(Added for debugging)
IOID_11 is "CS_wireless"

You understood logic trace correctly.

What am I doing wrong?

0 IUsedToBeARealPerson (M-W) over 8 years ago in reply to Gennadiy Pavlov

TI__Guru 58425 points

Could you provide some additional code on how you initialize the SPI driver, are it in callback or blocking mode?

0 Gennadiy Pavlov over 8 years ago in reply to IUsedToBeARealPerson (M-W)

Prodigy 170 points


/*    Last Version   */ 

SPI_Params SPI_DGSParams = {
    SPI_MODE_CALLBACK,  /* transferMode */
    50000,               //SPI_WAIT_FOREVER,   /* transferTimeout */
    NULL,               /* transferCallbackFxn */
    SPI_SLAVE,          /* mode */
    1000000,            /* bitRate */
    8,                  /* dataSize */
    SPI_POL0_PHA0,      /* frameFormat */
    (uintptr_t) NULL    /* custom */
};

In blocking mode same problem

0 IUsedToBeARealPerson (M-W) over 8 years ago in reply to Gennadiy Pavlov

TI__Guru 58425 points

That should be fine, you should stick with callback mode as blocking is not possible to use if you perform the transfer inside a callback function (or nay other Swi/Hwi context).

What mode are your device in before the transfer? I assume you let it go into standby to save power?
In this case you must remember that there is an delay of typically 150 us to transition from standby -> active (you can find this inside the datasheet). This seems to match well with the delay you are seeing.

If this is the case, you will have to take this into consideration on the master side to allow the device to wake up.

There is an example in the SPI driver documentation on how to implement a "Wake on CS" functionality and what the restrictions are. You will have to look inside the SDKs for the newer devices, but the idea remains the same on how to implement it.

Here is a quick link to the newest CC26X2 SDK, look for the "Wake Up On Chip Select Deassertion In Slave Mode Using SPI_MODE_CALLBACK" section.

dev.ti.com/.../_s_p_i_c_c26_x_x_d_m_a_8h.html

Bluetooth®︎

Bluetooth forum

CCS/CC2650MODA: Interrupt triggering CS SPI CC2650 Ti-RTOS