• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 992 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: Device to Host Synchronization word is not correct when using SPI

Bob Wayner
Prodigy 210 points
Part Number: CC3100


When attempting to use SPI to communicate between our microcontroller and an onboard CC3100, the CC3100 replies with an incorrect sync word. It replies with either 0x5E6E66D5 or 0x3CDCCDAB, from what our oscilloscope tells us. We have ruled out the power supply, the fast clock crystal, the slow clock crystal, and the MOSI data to the CC3100. I have attached scope plots to backup what we are seeing. Channel 1= CC3100 Chip select, Channel 2 = MOSI, Channel 3  = MISO and Channel 4 = CLK

Figure 1: Signals during powerup.

Figure 2: Host to device Syncronization word: 0x65877856

Figure 3: Transaction of 4 packets of 0s.

Figure 4: Device to Host Sync word: 0x3CDCCDAB

We have a board with an on-board CC3100, but these plots were taken with our microcontroller connected to a CC3100BOOST board from TI and the on-board CC3100 depopulated, to attempt to eliminate any hardware issues from our end. From the MOSI transaction, it appears we are using the right SPI mode 0, and our SPI speed is below 1MHz, which does not violate maximum SPI speed numbers. An Atmel Cortex M4 processor is being used to interface with the CC3100.

Thank you for your help.

- Bob

  • 0
    TI__Expert 8255 points

    Hi Bob,

    Based on the device to host sync words you're seeing and the signal levels it looks like there is an issue on the MOSI line. Are there any layout issues interfacing the Atmel microcontroller to the CC3100?

    I'd also suggest slowing down the SPI CLK rate even further in order to rule out any significant parasitic effects on the line.

  • 0 in reply to Austin Tanner
    Prodigy 210 points
    Sorry, Channel two is MISO and Channel 3 is MOSI. I mispoke in my original post. From the way our project is designed, we are expecting MISO to be about 3V while the host is 3.3V. The CC3100 is powered by 3V.
  • 0
    Prodigy 210 points

    Update: I did find that the embedded software had hibernate hold-down time for 1ms. Changed it to 15 ms to respect the minimum 10ms hold-down time. Doing this has caused the CC3100 to only consistently produce the 0x5E6E66D5 output on MISO.

  • 0 in reply to Bob Wayner
    TI__Guru* 91206 points

    Bob -

    i think you need to clean up the SPI lines in general - you show alot of noise in your captures and significant ringing on the edges - your issue is either that or some kind of sync issue. .

    if you take what you are getting now and shift it by two bits (and this is a theory) - just  - you can start to derive the correct value.

    you should be getting

    0011 1100 1101 1100 1100 1101 1010 1011

     3         C         D        C         C      D        A        B

    you are getting

    0101 1110 0110 1110 0110 0110 1101 0101

       5        E        6         E        6        6         D       5

    thus, if you clean up the line / find a sync problem, you might get the correct values

    in this case, the ringing might not be bad enough to cause this, but it should still be cleaner -

    i would suggest here after taking care of that, to take another screen capture and arrange the Chip Select, MISO, MOSI and CLK lines so you can see what is going on, as well as the idle state. 

     

  • 0 in reply to Josh Wyatt
    Prodigy 210 points
    We had 1K series termination resistors between our Microcontroller and our CC3100. Shorting those has fixed this issue. This being said, I am surprised that this has caused MISO to be delayed by one bit as opposed to the bus collapsing. Josh, can you think of why termination resistors could cause a MISO bit shift on the CC3100? Thank you.

    PS I did take better scope plots and the waves were much cleaner, as I improved the grounding for the probes.
  • 0 in reply to Bob Wayner
    TI__Guru* 91206 points

    Bob -
    you shorted what? do you mean buffer or termination (resistors)? most likely you using buffer resistors and 1k would be a high value either way, and that value would introduced the delay (which was unwanted) because of the fact that a wire is not just a wire (its an inductor, a cap and a resistor, too). 
    Glad that worked out for you.

    JDW

  • 0 in reply to Josh Wyatt
    Prodigy 210 points

    Here is what resolved our issue:

    We have 1K in-series termination resistors in between the CC3100 and our microcontroller for MISO, MOSI and SCLK. When these resistors were shorted, SPI began to work as expected. Strangely enough, I did not see non-monotonic clock edges on my scope and I was even using an active FET probe for that test.