How to select Chip Select PIN for CC1310 SPI slave

Thank you very much for time of you all, I really had gone through very difficult time and i am asked to off from work for sometime, I really need to start my project again and see whether I understand the concepts and your answers,
I will give my comments and Verify Answer ASAP

Hi Derrick,

Thank you very much for your answer, yes now I got more understanding and 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?


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++;
}
}

Hi Muhammad,

What are the configuration settings of the BBB and your Arduino?
The two important settings:
params.frameFormat: the two most common modes are (POL=1 PHA =1) and (POL=0 PHA=0)
transaction.count: are you sure your BBB or Arduino are transferring 8 bytes.

I would start by trying to configure the SPI as POL=0 and PHA=0.

I don't have enough experience with the SPI driver to be much more help.

Regards,
Michel

I am using following configurations in BBB ,

SPIDevice spi(2,0); //Connect to the spi bus 2 in device 0
spi.setMode(SPIDevice::MODE0); //set SPI Mode to 0 ()
spi.setSpeed(1000000); // SPI Clock speed is 1MHz

As I read MODE0 is (POL=0 PHA=0) but I had to use params.frameFormat = SPI_POL1_PHA1; in TI-RTOS Task to at least receive first transaction correctly. I am not sure about the Arduino configs I used code found here
gist.github.com/.../3317769

I am sending a message (char array) "Hi Slave" from BBB but these are some of output I get in the console from the TI-RTOS code above?


[Cortex_M3_0] Starting the example
System provider is set to SysMin. Halt the target to view any SysMin contents in ROV.
Slave 0 Running:
Callback 0 Running: Hi SlaveH
Callback 1 Running: i SlafZ@!�
Callback 2 Running: �M��ٖ�!��
Callback 3 Running: M��-H$
m
Callback 4 Running: 2�Hi S]
Callback 5 Running: �iHi Slav
Callback 6 Running: e�
$M��-
Callback 7 Running: Hi 6�- H
Callback 8 Running: i Slave!�
Callback 9 Running: 6]�iH$6�
Callback 10 Running: fZ@$6�-
Callback 11 Running: Hi Slav- H
Callback 12 Running: i S]2Hi
Callback 13 Running: Slave !��

By default, the Atmel chips used on the Arduinos are configured in Mode 0 as well.
What is strange is that each callback returns 9 characters (instead of 8 as expected)...
So I looked at the github, and the code seems to be waiting for a new line ('\n') character (which would be your 9th character)
Have you tried reading 9 characters on the CC1310 to see whether that helps?
Michel

Hi Michel,

Thank you very much for your prompt responses, Yes the arduino code wait for '\n' character before printing the result to serial out, I changed it to wait for '\0' character and used my BBB master tx buffer 9th character also to '\0'. Everything worked fine with arduino.

But somehow I am more concerned about each byte transmitted being properly received in the slave side, otherwise we cannot even use the If condition used in the arduino code to check for '\n' or '\0' charcter.

Do you think the TI-RTOS System print function can cause any problem though the character in the received buffer are correct? BTW it also working fine when make the SPI transfer between two launchpads

Hi Muhammad,

There might be an issue with the way that TI-RTOS handles the data.

As you may already know, the master dictates what data is sent and received. However, this also means that the slave needs to know how much data to send (this is usually where it gets tricky because you need to specify this before the transfer).

The reason that the code in the arduino is working is because as soon as data is received, it is analyzed right away. In TI-RTOS, you cannot check what data is coming in (unless you use a transfer size of 1). In which case, you will enter the callback after every byte. This might be something worth trying (I've done this with the UART driver but not with the SPI) because it would emulate the behaviour of the arduino code.

You might run into problems if the SPI clock frequency is very high since MCU will spend most of its time calling the callback function to handle each byte.

Would you, by any chance, have a logical analyzer? This would help you tremendously in seeing exactly what is happening between the devices. You can get some fairly cheap ones online and they are very easy to use (look for Saeleae clones).

Regards,

Michel

Hi Michel,

Let me share my further findings on this isssue, so that you any one else can help me understanding the real issue or finding a solution,

1. When I do one byte by one byte data transfer I am receiving the proper byte , but we are working on application where we need to transfer large amount of data via SPI at once, That's again one of the reason we are trying to use SPI over UART, do you think transferring this way one byte by one byte will not reduce the time efficiency, any how this is a good suggestion and than you,I will try this and will let you know

2. When I also transfer multiple(8) 0x55 (10101010 in binary) characters with transaction count greater than 1, I am receiving correct multiple bytes, do not know what's happening in this scenario , seems like it's been shifted by some even number of bits so the shift register always hold the same byte value

3. But when I use any other characters of 8 byte I am receiving some random selected wrong bytes(Characters), can this be because of following concept?

Whenever there is an hardware interrupt(Hwi) for spi data, it's served immediately, but the software thread(Swi) running which is responsible for copying received data from shift register to defined received buffer is halted before the job done to serve another byte transferred (Hwi) and when it resumed Swi again the data in the shift register is altered?

4. The weird thing is Multiple different character transfer works well between two launchpads, but not with BBB and a LP?

I also observed all these behaviors, clock and data signals with oscilloscope, This concludes that the Master is sending the data and clock signals properly and the problem is on the TI-RTIOS Slave code or as you mentioned the way that TI-RTOS handles the data.

Muhammad Ramshad said:

1. When I do one byte by one byte data transfer I am receiving the proper byte , but we are working on application where we need to transfer large amount of data via SPI at once, That's again one of the reason we are trying to use SPI over UART, do you think transferring this way one byte by one byte will not reduce the time efficiency, any how this is a good suggestion and than you,I will try this and will let you know

I think you misunderstood what I meant when I menitoned the UART. You should not do SPI over UART because it will not work. UART only have an RX and TX line (without a clock or chip select pin). I said that I used UART for UART commnunication, but since I ddin't know the transfer length, I would tranfer one byte at a time.

Transferring one byte at a time will reduce time efficiency. But until we figure out  why you are not getting what you want, that is the only solution that currently works.

Muhammad Ramshad said:

4. The weird thing is Multiple different character transfer works well between two launchpads, but not with BBB and a LP?

The two launchpads use the same driver hence the same code and they use the same protocol (same mode and frequency and all other parameters are the same). I cannot say the same about the BBB.

Muhammad Ramshad said:

I also observed all these behaviors, clock and data signals with oscilloscope, This concludes that the Master is sending the data and clock signals properly and the problem is on the TI-RTIOS Slave code or as you mentioned the way that TI-RTOS handles the data.

Did you check on your oscilloscope how many bytes and what bytes were sent?

Also, whether the master was transferring in mode 0 or 3 (or possibly another mode). If you are unsure what these modes mean, here are a few links that will help you understand:

CC1310 TRM. You can go to section 20.4.4 Frame Formats (look for Motorola frame formats)

Another link

Muhammad Ramshad said:

2. When I also transfer multiple(8) 0x55 (10101010 in binary) characters with transaction count greater than 1, I am receiving correct multiple bytes, do not know what's happening in this scenario , seems like it's been shifted by some even number of bits so the shift register always hold the same byte value

3. But when I use any other characters of 8 byte I am receiving some random selected wrong bytes(Characters), can this be because of following concept?

Whenever there is an hardware interrupt(Hwi) for spi data, it's served immediately, but the software thread(Swi) running which is responsible for copying received data from shift register to defined received buffer is halted before the job done to serve another byte transferred (Hwi) and when it resumed Swi again the data in the shift register is altered?

The TI-RTOS driver uses the DMA and therefore there are no interrupts until the end of the transfer. The DMA handles everything.

It is still unclear to me whether you have bits shifted or bytes shifted in your data.

I would try sending a sequence a increasing characters from your master and see what you receive (ex: 0x31 0x32 0x33 .... 0x3A 0x3B...). On your master, make your buffer larger than you send so if you send 8 bytes, make your TX buffer 16 bytes just in case it sends more bytes. On your slave, do the same thing. If you expect 8 bytes, create a buffer that can contain double the size. If the TI-RTOS driver continues writing data, it will not corrupt any other variable in your code.

Regards,

Michel

Hi Michel,

Sorry about my bad English :) ,

What I meant by SPI over UART is using SPI instead of UART, I was able to receive multiple bytes of data between BBB and LP with UART_transfer function without any errors or byte losses.

I tried implementing one byte by one byte transfer in CALLBACK mode as the way it implemented for arduino, I am receiving bytes without errors, but unfortunately, there are entire byte losses in some transfer, our application cannot afford a single byte loss like this.

I am opening SPI handle only once and keep on calling transfer function in the callback. As Derrick suggested I have commented out all my System print calls and using break-points to check the content of rxBuf.

Here is  my new code,

int count = 0;
int cbcount=0;
uint8_t buf[160];
int i;
uint8_t txbuf[10]={'A','B','C','D','E','F','G','H'};
char rxbuf[10]={0,0,0,0,0,0,0,0,0,0};

SPI_Params params;

// Callback function
static void transferCallback(SPI_Handle handle, SPI_Transaction *transaction)
{
    //SPI_close(handle);
    //handle = SPI_open(Board_SPI0, &params);
    buf[count]=rxbuf[0];
    //if (rxbuf[0]=='\0'){
        //System_printf("Callback Running!!!! %s\n", buf); System_flush();
        //count=0;
    //}
    count++;
    SPI_transfer(handle, transaction);
}

Void slaveTaskFxn (UArg arg0, UArg arg1)
{

    UInt32 time1, time2, delta;

        SPI_Handle handle;
        SPI_Transaction transaction;

        SPI_Params_init(&params);
        params.transferMode        = SPI_MODE_CALLBACK;
        params.transferCallbackFxn = transferCallback;
        params.transferTimeout     = SPI_WAIT_FOREVER;
        params.bitRate             = 1000000;
        params.frameFormat         = SPI_POL1_PHA1;
        params.mode                = SPI_SLAVE;
        params.dataSize            = 8;


        transaction.count = 1;
        transaction.txBuf = &txbuf;
        transaction.rxBuf = &rxbuf;


        while(1)
        {
    //        time1 = Timestamp_get32();

            handle = SPI_open(Board_SPI0, &params);
//            while (Board_SPI0_CSN==1);
            SPI_transfer(handle, &transaction);
            while(true);
            SPI_close(handle);

    //        time2 = Timestamp_get32();
    //        delta = time2 - time1;
        }
}



As I observed in the oscilloscope (attached here), the Master BBB  sending correct number(8) of  defined bytes. I also have good understanding about modes and verified it with oscilloscope. As you said, I also tried sequence of increasing character set, we faced the same data error problem.

The first image  shows the 8 bytes of clock signals(yellow) and the data transferred(purple)  and the Chip Select Signal(Blue), the second image is zoomed in version of one byte.

Now I must at least make one byte by one byte transfer work without byte losses. Further I also would like to know, are these data errors and byte losses usual with SPI communication? If so is this normally handled by drivers.

The other questions are, are there any difference in how UART is handle in TI-RTOS compared to SPI?

Hi Muhammad,

Can you send only one transaction at a time from your BBB (increase the time between each transfer)?

From the image that you posted, there is approximately 600us between each transfer. That seems very short to do anything else.

Also, from the oscilloscope, I see that the mode is indeed POL=0 and PHA=0 (bits are toggled on the falling edge and sampled on the rising edge; the clock idle seems to be 0). Your code still shows

params.frameFormat = SPI_POL1_PHA1;

Muhammad Ramshad said:

I tried implementing one byte by one byte transfer in CALLBACK mode as the way it implemented for arduino, I am receiving bytes without errors, but unfortunately, there are entire byte losses in some transfer, our application cannot afford a single byte loss like this.

By transferring one byte for each transfer (your SPI frequency is set to 1000000Hz), you have very little time to do anything. My guess is the CC1310 is constantly overloaded. If the BBB starts another transfer before the CC1310 can setup another transfer, you will lose bytes for sure. 

So as I just mentioned, send one transfer at a time (you can change the transfer "size" to 8), but pause your BBB between each transfer. Also, break inside your callback to make sure that the bytes are properly received.

Regards,

Michel

Hi Michel,

Again apologize me for my bad reporting,  I will make sure this won't  happen again

The oscilloscope images and the code I have shared are from two different tests. I actually tried the same modes as well as tried all possible different combination of modes  between BBB and LP.

Yeah, I tried your latest suggestion as well, I am running the above shared slave code and using the break point  before next SPI transfer call inside callback function. I am running my BBB Msater in Mode3, I am only sending one byte in every manual execution of my Master code (So the slave  has more than expected delay (few 10 seconds) ) still certain bytes are not received  on slave side.

How I am trying is,I am  manually execute my following master code (So it does only one byte transfer when I execute )  and checking the rxbuf and buf in the launchpad , What I am expecting is, for every execution of my master code the 'H' character should be filled in rxbuf[0] and it's should have been added to buf.

For  first few (2/3) execution of Master code slave receive the 'H' character in rxbuf[0] and fills/append to buf[] as well, then again for one or two execution Slave receives nothing in rxbuf[0], it doesn't even call  the call back function, there after on my third and following executions it receives 'H' character to rxbuf[0] and keep on filling buf[]. This pattern continues in random manner (I mean non receiving byte  pattern is randomly happening)

But I think there is a one clue that you can help me with,
Every time when I don't receive the byte on the Slave LP, I am reeving wrong character on the receive buffer of Master, It actually should be character 'A'  defined in the Slave txbuf

Do you think that the LP Slave code is busy with preparing it's txbuf while it receiving and hang some where?

//BBB Master

int main(int argc, char* argv[]){

       SPIDevice spi(1,0); //Connect to the spi bus 1 in device 0

spi.setMode(SPIDevice::MODE0); //set SPI Mode to 0 ()

spi.setSpeed(1000000); // SPI Clock speed is 1MHz

spi.open();

      cout << "SPI Device 1.0 is opened" << endl;

       unsigned char send[8]={0x55,0x55,0x55,0x55,0x55,0x55,0x55,0x55}, receive[8];

const char* message="Hi Slave";

//memset(send, 0, sizeof send);

//memset(receive, 0, sizeof receive);

int i;

for (i=0; i< 8; i++){

send[i] =  *(message+i);

//cout << send[i] << endl;

}

send[8]=0;

       cout << "SPI Send: " << send[0] << endl;

        for (i=0;i<1;i++){

spi.transfer(send+i, receive, 1);

//usleep(100000);

 }

      cout << "SPI Received: " << receive[0] << endl;

spi.close();

}

//LP Slave

int count = 0;

int cbcount=0;

uint8_t buf[160];

int i;

uint8_t txbuf[10]={'A','B','C','D','E','F','G','H'};

char rxbuf[10]={0,0,0,0,0,0,0,0,0,0};

SPI_Params params;

// Callback function

static void transferCallback(SPI_Handle handle, SPI_Transaction *transaction)

{

//SPI_close(handle);

//handle = SPI_open(Board_SPI0, &params);

buf[count]=rxbuf[0];

//if (rxbuf[0]=='\0'){

//System_printf("Callback Running!!!! %s\n", buf); System_flush();

//cbcount=0;

//}

count++;

SPI_transfer(handle, transaction);

}

Void slaveTaskFxn (UArg arg0, UArg arg1)

{

UInt32 time1, time2, delta;

   SPI_Handle handle;

   SPI_Transaction transaction;

   SPI_Params_init(&params);

   params.transferMode        = SPI_MODE_CALLBACK;

   params.transferCallbackFxn = transferCallback;

   params.transferTimeout     = SPI_WAIT_FOREVER;

params.bitRate             = 1000000;

params.frameFormat         = SPI_POL1_PHA1;

params.mode                = SPI_SLAVE;

   params.dataSize   = 8;

   transaction.count = 1;

   transaction.txBuf = &txbuf;

   transaction.rxBuf = &rxbuf;

   while(1)

{

// time1 = Timestamp_get32();

handle = SPI_open(Board_SPI0, &params);

// while (Board_SPI0_CSN==1);

SPI_transfer(handle, &transaction);

while(true);

SPI_close(handle);

// time2 = Timestamp_get32();

// delta = time2 - time1;

}

}

/*

*  ======== main ========

*/

int main(void)

{

   Task_Params SlavetaskParams;

   /* Call board init functions */

   Board_initGeneral();

   //Board_initI2C();

   Board_initSPI();

   /* Construct heartBeat Task  thread */

   Task_Params_init(&SlavetaskParams);

   SlavetaskParams.arg0 = 1000000 / Clock_tickPeriod;

   SlavetaskParams.stackSize = TASKSTACKSIZE;

   SlavetaskParams.stack = &task1Stack;

   Task_construct(&task1Struct, (Task_FuncPtr)slaveTaskFxn, &SlavetaskParams, NULL);

   /* Open LED pins */

   ledPinHandle = PIN_open(&ledPinState, ledPinTable);

   if(!ledPinHandle) {

       System_abort("Error initializing board LED pins\n");

   }

   PIN_setOutputValue(ledPinHandle, Board_LED1, 1);

   System_printf("Starting the example\nSystem provider is set to SysMin. "

                 "Halt the target to view any SysMin contents in ROV.\n");

   /* SysMin will only print to the console when you call flush or exit */

   System_flush();

   /* Start BIOS */

   BIOS_start();

   return (0);

}

Hi Michel,

Found an interesting clue for the SPI Problem, when the Oscilloscope probe being connected to Chip Select pin or when I short circuit Chip Select PIN with GND , both single byte and multiple byte transfers work perfectly.

Also, I checked the LP to LP SPI Transfer and observed the Signals Oscilloscope, With LP Master, when i send multiple bytes the Chip Select PIN is low until the specified number(4) of byte are transferred and I observed 4*8=32 nice cleaner clock toggles without any pauses or idle time between bytes.

But with BBB Master, I could observe a small idle time between each bytes of multiple bytes (You can see this in the images I already have shared),  I also observed BBB Chip Select pin separately in the oscilloscope, the Chip select remains low  during this clock idle period, So I suspect , in this case (BBB Master) whether the BBB find it difficult to drive LPs Chip Select PIN Low due to its PIN Configurations.

Here are the configurations I am using for SPI Slave,

//CC1350_LAUNCHXL.h

* SPI Board */
#define Board_SPI0_MISO             IOID_8          /* RF1.20 */
#define Board_SPI0_MOSI             IOID_9          /* RF1.18 */
#define Board_SPI0_CLK              IOID_10         /* RF1.16 */
#define Board_SPI0_CSN              IOID_24
#define Board_SPI1_MISO             PIN_UNASSIGNED
#define Board_SPI1_MOSI             PIN_UNASSIGNED
#define Board_SPI1_CLK              PIN_UNASSIGNED
#define Board_SPI1_CSN              PIN_UNASSIGNED

//CC1350_LAUNCHXL.c

const PIN_Config BoardGpioInitTable[] = {

    Board_RLED   | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,         /* LED initially off             */
    Board_GLED   | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,         /* LED initially off             */
    Board_BTN1   | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS,            /* Button is active low          */
    Board_BTN2   | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS,            /* Button is active low          */
    Board_SPI_FLASH_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MIN,  /* External flash chip select    */
    Board_UART_RX | PIN_INPUT_EN | PIN_PULLDOWN,                                              /* UART RX via debugger back channel */
    Board_UART_TX | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,                        /* UART TX via debugger back channel */
    Board_DIO1_RFSW   | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MAX,   /* RF SW Switch defaults to sub-1GHz path*/
    Board_DIO30_SWPWR | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MAX,    /* External RF Switch is powered on by default */
    Board_SPI0_MOSI | PIN_INPUT_EN | PIN_PULLDOWN,                                            /* SPI master out - slave in */
    Board_SPI0_MISO | PIN_INPUT_EN | PIN_PULLDOWN,                                            /* SPI master in - slave out */
    Board_SPI0_CLK | PIN_INPUT_EN | PIN_PULLUP,                                             /* SPI clock */
    //Board_SPI0_CSN  | PIN_INPUT_EN | PIN_PULLDOWN | PIN_DRVSTR_MIN,
    Board_SPI0_CSN | PIN_INPUT_EN | PIN_PULLDOWN,  //////////////////////////////

    PIN_TERMINATE
};

/* SPI configuration structure, describing which pins are to be used */
const SPICC26XXDMA_HWAttrsV1 spiCC26XXDMAHWAttrs[CC1350_LAUNCHXL_SPICOUNT] = {
    {
        .baseAddr           = SSI0_BASE,
        .intNum             = INT_SSI0_COMB,
        .intPriority        = ~0,
        .swiPriority        = 1,
        .powerMngrId        = PowerCC26XX_PERIPH_SSI0,
        .defaultTxBufValue  = 0,
        .rxChannelBitMask   = 1<<UDMA_CHAN_SSI0_RX,
        .txChannelBitMask   = 1<<UDMA_CHAN_SSI0_TX,
        .mosiPin            = Board_SPI0_MOSI,
        .misoPin            = Board_SPI0_MISO,
        .clkPin             = Board_SPI0_CLK,
        .csnPin             = Board_SPI0_CSN
    },
    {
        .baseAddr           = SSI1_BASE,
        .intNum             = INT_SSI1_COMB,
        .intPriority        = ~0,
        .swiPriority        = 1,
        .powerMngrId        = PowerCC26XX_PERIPH_SSI1,
        .defaultTxBufValue  = 0,
        .rxChannelBitMask   = 1<<UDMA_CHAN_SSI1_RX,
        .txChannelBitMask   = 1<<UDMA_CHAN_SSI1_TX,
        .mosiPin            = Board_SPI1_MOSI,
        .misoPin            = Board_SPI1_MISO,
        .clkPin             = Board_SPI1_CLK,
        .csnPin             = Board_SPI1_CSN
    }
};


Will you be able to help me on this with my further findings?

Thanks in advance

Hi Muhammad,

From what I can see in your code, the slave CS pin is configured as a pull down. And from what I understand, the devices are configured to be active low. So you're keeping the CS pin towards GND already. That might be the issue that you are talking about with the BBB not being able to drive the CS pin.

Two things to try:
1- Set the CS pin to use a pull-up.
2- Disable all pulls on the CS pin (I don't know whether there is an option to disable the pull (ex: PIN_NOPULL), or if removing the PIN_PULLDOWN is sufficient.

Regards,
Michel

Hi Michel,

Thanks for the suggestions,
Tried following three different pin configurations, but still the status is same, :(

//Board_SPI0_CSN | PIN_INPUT_EN | PIN_NOPULL,
//Board_SPI0_CSN | PIN_INPUT_EN | PIN_NOPULL | PIN_IRQ_NEGEDGE,
Board_SPI0_CSN | PIN_INPUT_EN | PIN_NOPULL | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, //////////////////////////////

I keep on observing the signals with oscilloscope, I can see lots of noise (significant (<~2.3V) spikes) in the chip select pin of LP , but when I connect it to LP GND PIN the spikes strengths are reduced (<~0.6 V). So the transfer works fine.

If you get any other ideas on this, Please let me know

Thanks

Hi Muhammad,

Have you tried the configuration with the pull-up?

The spikes are the IC try to drive a 1 on the CS line, but something is keeping it down (when you plug it to ground).

Can you drive the CS pin on the BBB yourself?
If possible, I would suggest adding a delay between when you set CS to 0 and when you start sending the data.
If not, you could use another IO (other than CS) and connect that new pin to the CS of your LP. So you will control when CS is set and unset.

I think I've run out of ideas.

Regards,

Michel