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.

CC3301: Setting up SPI with CMD0 - Flags and Formatting

Part Number: CC3301

Tool/software:

My setup:

  • Custom board with the CC3301 companion chip
  • Probe on the SPI-ports

Goal:

  • Setting up SPI communication between host MCU and CC3301 by sending CMD0

When CMD0 is sent, the probe reads the following sequence of bytes: 0x00, 0x80, 0xFE, 0xFF, 0x73, 0xF2, 0x10, 0x00 (big endian, no bit swizzle)
When reordered based on data endianness and a wordsize of 32 bits: 0xFFFE80000010F273. This data-sequence does not result in the  MISO channel falling to LOW after the last bit of CMD0 has been sent -- which I understand to indicate that the CC3301 understands the settings of the SPI  packages to follow. Looking at the sequence of bytes (and keeping the left bitshift from `bus_sendInitCommand(...)` in mind), the  `de`-flag is set to 0 -- little endian.

If I manually set the flag high in the function by adding the following line just before the aCRCBuffer is populated:

aTempCmd0[6] = initCmd[5] |= 2;

The sequence is changed to 0x00, 0x80, 0xFE, 0xFF, 0x3B, 0xF6, 0x10, 0x00, however, the result remains the same -- no response on the MISO channel.



If, however, I manually reorder the bytes from the code, so that the sequence of bytes is: 0xFF, 0xFE, 0x80, 0x00, 0x00, 0x10, 0xF2, 0x73, IT WORKS! 

However, this is not a good solution in my case, since the byte-order will be wrong everywhere else. This also indicates that the enable signal for chip is properly set up -- and there must be something wrong with how I send the CMD0, where my guess is the formatting.


This has lead me to formulate some questions:

1. Is CMD0 supposed to be sent using little endian and without bit-swizzle under any circumstance OR should it follow the formatting specified in the internal flags?  
2. In the function `bus_sendInitCommand(...)` the parameter `config_params` is disregarded and a local `uint32_t config` is initialised and used instead - How am I supposed to change the `de`-flag then?
3. Is my assumption about "MISO channel falling to LOW" indicating that the CC3301 understands the settings of the SPI  packages to follow?
4. Is there a command I can send to the CC3301 to see if it is able to respond?


Thanks in advance,

    Albert

  • Hi,

    Not sure what you want to change on the original command (haven't dived to the bits in this function) but the final command should be as in the second picture that is working.

    dropping MISO line is the indication that the chip responds.

    yes, you should refer to the config instead (I assume it was prepared for external control over the configuration but never used).

    Shlomi

  • Hi,

    In order to send the command seen in the second image I have to modify the function `bus_sendInitCommand(...)`, meaning that the SPI setup on my MCU is incongruent with the default SPI settings in the CC3301-drivers. That is the reason why I asked question no. 1, because I wanted to know whether or not I can manually force-send the byte-sequence from image 2 and then afterwards follow the formatting specified in the internal flags of the byte-sequence?

    Albert


  • Hi,

    Again, not sure why you had to manually change the bus_sendInitCommand() but the code is hard coded to 32 bits mode, little endian.

    I can try to find out internally but I do not think it supports other combination at the moment.

    Regards,

    Shlomi