RTOS/LAUNCHXL-CC1310: SPI Data Error when use as Slave device

Muhammad Ramshad

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Tool/software: TI-RTOS

I got more understanding about TI-RTOS and SPI Libraries after posting a question in the e2e forum , Now SPI Slave is working fine in both BLOCKING and CALLBACK mode.

But now the problem is when I set the SPI transaction count to more than 1 (multiple bytes at a time) it's working fine between two launchpads, but when I replaced Master with Beaglebone Black, the launchpad doesn't decode/sample the received byte properly, there are lot errors in the received byte/characters.

I tested my BBB Master code with arduino (act as Slave) it was working fine,

I have spent more than week on this problem now, I tested with changing transfer rate (from min to max) and changing SPI Modes etc, Nothing helps.

I would like to know what I am missing in the Launchpad's Slave code?

Is it something to do with any configurations in the Launchpad code? Is this something to do with the clock speed of cc1310 is far less than the BBB

Here is my slave code with Callback function

// Callback function
static void transferCallback(SPI_Handle handle, SPI_Transaction *transaction)
{
// Start another transfer
//transaction->count = 1;
//System_printf("Status: %.*s\n",8, transaction->status); System_flush();
//for (i=0; i<8;i++){
// rxbuf[i]=0;
//}
SPI_transfer(handle, transaction);
System_printf("Callback %d Running: %c%c%c%c%c%c%c%c\n", cbcount, rxbuf[0],rxbuf[1],rxbuf[2],rxbuf[3],rxbuf[4],rxbuf[5],rxbuf[6],rxbuf[7]); System_flush();
for (i=0; i<8;i++){
rxbuf[i]=0;
}
cbcount++;

}

Void slaveTaskFxn (UArg arg0, UArg arg1)
{

UInt32 time1, time2, delta;

SPI_Handle handle;
SPI_Params params;
SPI_Transaction transaction;
//uint8_t txbuf[8]={'A','B','C','D','E','F','G','H'};
//uint8_t rxbuf[8]=0;

// Init SPI and specify non-default parameters
SPI_Params_init(&params);
params.bitRate = 1000000;
params.frameFormat = SPI_POL1_PHA1;
params.mode = SPI_SLAVE;
params.transferMode = SPI_MODE_CALLBACK;
params.transferCallbackFxn = transferCallback;
// Configure the transaction
transaction.count = 8;
transaction.txBuf = txbuf;
transaction.rxBuf = rxbuf;
// Open the SPI and initiate the first transfer
handle = SPI_open(Board_SPI0, &params);

while(1)
{
time1 = Timestamp_get32();
SPI_transfer(handle, &transaction);
//Task_sleep(10000);
//rxbuf[8]='\0';
System_printf("Slave %d Running: %s\n", count, rxbuf); System_flush();
//Task_sleep(10000);
//System_printf("Slave Running: %s\n", rxbuf); System_flush();
while(true);
//SPI_close(handle);
time2 = Timestamp_get32();
delta = time2 - time1;
System_printf("Time taken: %d\n",delta); System_flush();
count++;
}
}

over 7 years ago

0 Ramsey over 7 years ago

TI__Genius 12025 points

Muhammad,

You indicate that the BeagleBone Black is issuing multiple SPI transfers. Are they back-to-back? How much time between transfers?

If the CC1310 SPI slave does not process the current transfer and prime the next transfer quickly enough, the next transfer will be lost. This work happens in your callback function. I notice that you are calling System_printf() and System_flush() inside of your callback function. This is generally not recommended. Keep in mind that your callback function runs in the context of an interrupt. This means your callback function must not block. Depending on which system provider you are using, the calls to System_printf() and System_flush() might be taking a long time.

I would suggest that your SPI callback function place the data in a queue and signal a task for processing. Then it should immediately prime the next SPI transfer. Also, slow down the SPI transfers from the BBB until you have success. Then increase the transfer rate until you reach the saturation point. Remember, your slave needs time to process the transfer in order to keep up. Regardless if the processing is done in the callback or in a task.

~Ramsey

0 Muhammad Ramshad over 7 years ago in reply to Ramsey

Prodigy 140 points

Hi Ramsey

Thank you very much for your response, I didn't notice your response since I have been discussing this isssue in another post as well.

Now after whole efforts and findings, When I use SPI Master as BBB or Arduino, I am stuck in a point where the SPI Chip select PIN assertion has more noise( spikes), it seems the data error happens due to this. But when I use another launchpad as Master everything works fine.

I wonder why BBB and Arduino cannot drive LP's Chip Select PIN to low without theses noise (spikes) .

If this is due to LP PIN Configurations, do you know what are the correct PIN Configuration for salve Chip Select PIN? Or can any one please tell me why Chip Select PIN is not stable when asserted ?

Thanks

0 Ramsey over 7 years ago in reply to Muhammad Ramshad

TI__Genius 12025 points

Muhammad,

I have read through your other forum post. It seems like you have been working this issue for a long time. Have you come to a resolution or is this still an outstanding issue which needs to be resolved?

Also, what operating system are you running on the BeagleBone Black? Is it Linux? If so, which distribution are you using and how did you configure the SPI driver?

~Ramsey

0 Muhammad Ramshad over 7 years ago in reply to Ramsey

Prodigy 140 points

Hi Ramsey,

As mentioned in other post, now I could solve all the problems, My SPI Communication is working fine after common ground connection and having speed limit to <6MHz. Both master and slave receives correct data(bytes).

I am using Embedded Linux (Debian GNU/Linux 7.4 (wheezy)) and I am using Linux spidev driver for SPI communication.

Thank you for your time and response

0 Ramsey over 7 years ago in reply to Muhammad Ramshad

TI__Genius 12025 points

Muhammad,

Very good. Best of luck on your project

~Ramsey

Sub-1 GHz

Sub-1 GHz forum

RTOS/LAUNCHXL-CC1310: SPI Data Error when use as Slave device