• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 42 subscribers
  • Views 1391 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.

CC3100 Sync-Word shifted by 4 bits

Bruno Paillard
Intellectual 945 points

Other Parts Discussed in Thread: CC3100

Hi I am seeing a problem where the sync word coming back from the CC3100 is off by 4 bits.

This seems to occur only when some of the SPI bytes are close together, but does not seem related to the actual SPI clock frequency.

In the example attached the first non-zero response from the CC3100 to the host starts with a 0x0B at the end of one frame, and the rest of the sync word in the next frame: 0x00 - 0x00 - 0x00 - 0x0B, then 0xCD - 0xCC - 0xDA - 0xB0, instead of 0x00 - 0x00 - 0x00 - 0x00 then 0xBC - 0xDC - 0xCD - 0xAB

-The SPI clock is only at 4 MHz

- The separation between the two first bytes of the frame is only 560 ns (This SPI module can send the two first bytes very close together)

- It is difficult to see on the picture, but there are NO spurious clock transitions anywhere. The clock is very clean and well synchronized to the CS

-The first image shows the host initiating the sync word (sending 0x65 - 0x87 - 0x78 - 0x56)

- There is a frame of zero following that initiating frame (not shown)

- The second image shows the first frame where the CC3100 does not send back all 0x00s, and the frame after that one (with the 4-bit shifted Sync Response from the CC3100)

  • 0
    TI__Mastermind 27625 points
    Hi Bruno,

    Can you try reducing the SPI clock speed to something slower, say 100 kHz? This is just a debugging idea. Can you provide clearer screen captures of your SPI signals as well? It looks there is a lot of ringing...

    Thanks,
    Aaron
  • 0 in reply to made4engineering
    Intellectual 945 points

    Hi Aaron

    - Yes. The ringing is because we did not have enough physical room to ground all the probes. But if/when we ground all the probes the signals look much better. In other words the ringing is a product of bad probing, not bad signals. The following points will shed a bit more light on the problem:

    - Reducing the shift clock eliminates the problem, but of course, reducing the shift clock also increases the time between each byte. So that does not tell much.

    - To try to confirm if the problems comes from a bad (or too fast) clock, or really from bytes that are too close, we did the following: The two bytes that are very close together are due to a hardware double buffer in the SPI system. The SPI is able to absorb the first two bytes very quickly. To avoid that, we now only send a new byte only when the previous one has been TRANSMITTED. That increases the gap between bytes. With that modification we are able to increase the clock frequency to 16 MHz without problems. This tells me that  the SPI clock frequency is not the issue.

    - Another possible issue is that the first bytes may be sent too close after the CS is brought active...

    Is there a limit on the time between bytes?

    Is there a limit (a setup time) between CS active and the first byte?

  • 0 in reply to Bruno Paillard
    TI__Mastermind 27625 points
    Hi Bruno,

    Can you send an updated screenshot? What host microcontroller are you using?

    Thanks,
    Aaron
  • 0 in reply to made4engineering
    Intellectual 945 points
    Hi Aaron

    I have to apologize for wasting your time. The problem was a spurious byte transmission exactly between the first and the second JPG that I posted. That extra byte transmission occurred while the CS was being de-asserted, and therefore we could have just a few extra bit clocks... Obviously (and predictably) that caused the problem described.
    We just did not see it, even though it was very obvious!

    Sorry again!

    Bruno