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.

CC3220SF-LAUNCHXL: Im not sure i understand SPI_transfer and spiTransaction

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

I have no idea why this wont work, but I'm getting really dishearten from this...  Here's what's going on...

My SPI device accepts commands in 16 bit data frames.  So, when I set up my SPI object I give it the parameter "spiParams.dataSize = 16" but everything still comes through in 32 bit!

Next, when I set the value of spiTransaction.txBuf it does not change.  In this example I set it to transmitBufferRead which is 0xFFFF but as you can see tx buf stays at 0x2000067C?

I'm really not sure what I'm doing anymore, I'm really just trying to send 0xFFFF over SPI and receive a 16 bit value back...  Bit 15 is a parity bit, bit 14 is the command frame bit, and bits 13:0 is the data I'm looking for.

  • Hi,

    Can you please send your a copy of the project?

    Regards,
    Charles O
  • Hi James,

    spiTransaction.txBuf is a pointer. On a 32bit addressed device such as the CC3220SF, all pointers to memory locations will be 32bits wide. It doesn't matter what data type the pointer is meant to be pointing to, the actual value of the memory address stored in the pointer will be 32bits.

    Now, transmitBufferRead is a pointer to an array of uint16. As it is a pointer, the actual value stored by transmitBufferRead is also 32bits. However, since CCS knows that the memory address stored in transmitBufferRead is actually a reference to the start of an array of uint16, it will helpfully dereference it in the variable viewer and tell you what is in the array pointed to by transmitBufferRead.

    When you do your spiTransaction.txBuf = transmitBufferRead assignment, you are correctly setting the SPI Tx buffer to point to your array. However, as CCS does not know what a void pointer might be pointing to, it simply displays the memory address that the pointer is pointing to in the variable viewer. If you go open the memory browser (View->Memory Browser) and type in the address pointed to by spiTransaction.txBuf (0x20000067C in your example screenshot), you will see 0xFFFF stored in that memory location. This is consistent with the SPI Tx buffer assignment.

    You can read more about how pointers work here:

    en.wikipedia.org/.../Pointer_(computer_programming)

    By the way, if you want to send 0xFFFF to your SPI slave and get a response back, there are a few things you should do:
    1. Make sure you check whether your SPI slave expects CS active high or active low
    2. Make sure you check whether your SPI slave has the same clock polarity and phase settings
    3. Make sure your SPI slave can support the clock rate selected
    4. Make sure you call SPI_transfer() again with a rx buffer assigned. Assuming your SPI slave has to read the full 16 bit word before returning a 16bit response, you will need to clock the SPI interface for a total of 2 words.

    I hope that helps you with your SPI problems. If you have any further problems, please use a logic analyzer to capture the output of the SPI_transfer() call to see if there might be some hardware issue that might be causing your problem.

    Regards,
    Michael
  • Good Morning Charles,

    Here is a link to my project: drive.google.com/open

    I made some progress since yesterday, however the results are not consistent and I'm not sure if I'm receiving good or bad data from the board yet. Still progress is progress!
  • Hi Michael,
    This makes so much more sense now. I was really getting frustrated but you pointing out (get it) that txBuf and rxBuf are pointers really set me straight, and I've made some progress on the application! Thank you for taking the time to write that out!
    -James