• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 301 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3220S: SPI Communication between CC3220S and CC2642R || Getting bit shifted data some times

Abhishek Pratap Singh
Intellectual 425 points
Part Number: CC3220S
Other Parts Discussed in Thread: CC2642R

Hi,

I am using SPI protocol to communication between CC3220S(Master) and CC2642R(Slave) chipset on custom board.

While communicating sometimes I get bit shifted data on the SPI, sometimes shifted by 1 bit and sometimes shifted by 2 bits.(Both of these shifting are not concurrent i.e. if 1-bit shifting is there it will be present till we reset the board, similar in case of 2-bit shift). I am not able to locate the source of this issue. Is there some issue with the compatibility of these two MCU SPI? I am trying to Understand what all can be possible reasons for this type of behavior, and it will certainly be helpful if it is already known and resolved by someone.

Following is my settings ---

WiFi SPI settings----------------------------

spiParams.mode = SPI_MASTER;
spiParams.frameFormat = SPI_POL1_PHA1;
spiParams.transferMode = SPI_MODE_BLOCKING;
spiParams.bitRate = 4000000;
spiParams.dataSize = 8;
spiParams.transferTimeout = 1000000;
spiParams.transferCallbackFxn = NULL;


BLE SPI settings----------------------------

spiParams.mode = SPI_SLAVE;
spiParams.frameFormat = SPI_POL1_PHA1;
spiParams.transferMode = SPI_MODE_BLOCKING;
spiParams.transferTimeout = 5000000;
spiParams.transferCallbackFxn = NULL;

  • 0
    TI__Mastermind 40965 points

    Hi,

    There are a variety of reasons which could result in SPI bit shifting, ranging from HW issues to driver bugs to other threads in your application interrupting the SPI transfer thread at an inopportune time.

    That being said, there shouldn't be an issue in SPI communication between the CC3220 and the CC2642R as the SPI driver and peripheral is tested at the max clock rate for each device. A few debug steps that you could try:

    1. Try running a simple SPI test between the CC3220 and the CC2642R using the TI launchpad EVMs. This would eliminate the potential issues that might be due to the HW design of your board. If you could perform a SPI test similar to what you're running on your custom board, do you see the same bit shifting?
    2. Do you see the same bit shifting at all if you lower the SPI clock rate?
    3. Have you checked the SPI signals with an oscilloscope to ensure that the signals conform to spec, especially for the SPI clock signal?

    It would be appreciated if you could answer those debug questions,

    Thanks,
    Michael

  • 0 in reply to Michael Reymond
    Intellectual 425 points

    Hi Michael,

    Thanks for your suggestion. Please find the following responses for each point:

    1. I have done this test before on the eval kits with just using SPI driver in three wire mode(CLK, MISO, MOSI). At time I was running the setup in debug mode and in that also I found that few times that data was getting bit shifted as visible in the watch window. At the time I was advised by my team that "it might be because of debug mode" and when I tried without it, it seemed to work at that time.
    2. I have not tried to lower the clock yet.
    3. No I have not checked on oscilloscope yet, as I wanted to look more into code for the resolution.

    Also I have one more input form my findings, when I am using UART_control(g_uart, UART_CMD_RXDISABLE, NULL) on cc3220s after this I am getting next SPI transfer data to be shifted by either 1-bit, 2-bit or 3-bit. I am not able to get why it is happening so, but it seems closing SPI before this line on cc3220s SoC and re-initializing SPI after this lines solves the problem. Same I have observed in case I have called UART_close() function.

    Even though my issue is resolved for now I still want to understand how UART functions are affecting SPI, because I am not sure if it will stop working at some point.

    Thanks,

    Abhishek

  • 0 in reply to Abhishek Pratap Singh
    TI__Mastermind 40965 points

    Hi Abhishek,

    The UART_control() function should not impact the performance of the SPI peripheral as all UART_CMD_RXDISABLE does is it disables the UART RX interrupts used by the UART driver.

    That being said, if closing and reopening the SPI interface so that the UART_CMD_RXDISABLE command is not used fixes your problem then you can keep doing that.

    Let me know if you need more clarification or have further questions on the CC32xx SPI peripheral.

    Regards,

    Michael