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.

CC3100MOD: CC3100MOD SimpleLink-Host Driver timing requirements?

Part Number: CC3100MOD
Other Parts Discussed in Thread: CC3100

Dear all,


my customer is trying to connect the CC3100MOD via SPI to a host MCU and is facing SPI communication issues when switching off the CC31xx SPI Debug feature. Adding a delay of ~1ms between each SPI telegram, it seems to work again.

Questions are:

Are there specific timing requirements defined between SPI telegrams?

Are there any error handling mechanisms implemented on the SPI-host drivers, to recover from erroneous telegrams?

Thanks,

BR,
Matthias

  • Hi Matthias,

    I have seen instances where small delays are needed in between CS transitions and SPI data, but not in between every word. There is no specification for this. It may have to do with making sure the CS line deasserts only after the last SPI word is sent. I can see an instance where the CS line may not actually be correctly synchronized when it is handled manually
    -Aaron
  • Hi Aaron,


    The customer is not looking for particular timing between single bytes. The question is, if there are any timing requirements between SPI-telegrams, when communicating between a host MCU and the CC3100.

    The other remaining question is, if there are any error handling mechanisms implemented on the SPI-host drivers, to recover from erroneous telegrams?

    This question has not been answered yet.


    BR,

    Matthias

  • Hi Aaron,


    any update on this open questions?

    Thanks,
    BR,

    Matthias

  • Hi Matthias,

    The host driver will take care of when the messages are sent and received.There is no error correction implemented in the host driver, but if an error is detected in the synchronization, the host driver will throw an error event. For the hardware interface timing requirements refer to the datasheet. My advise regarding the control of the CS line was simply to make sure it didnt transition in the middle of a word transfer. There shouldnt be anything else. The SPI clock rate goes up to 20 MHz, so design the traces accordingly.

    -Aaron

  • Hi Aaron,

    the customer is NOT talking about the SPI-timing itself (relationship between CLK, MISO and MOSI)!

    They are talking about timing between two SPI-Frames (one frame including multiple bytes).

    They have now experimented with different IdleTimes between two SPI-Frames (see graph below). They have observed, that for IdleTime >20us between multiple SPI-Frames the communication seems to work reliable.

    If the IdleTime is <20us, they do see SPI communication issues which can even result in hang-up of the SPI-driver. In this case, there is no error event coming up. The only way to recover seems to be a reset of the SPI-module from a higher prioritized task.

    So it looks like the CC3100 needs some time (>20us) in order to handle one SPI-Frame and before the next SPI-Frame can be handled.

    I hope this illustrates the question in a better way. Otherwhise we need to take this communication offline.

    Please have a look at it and get back to us.

    Thanks,

    BR,

    Matthias

  • Have you looked at the HOST_IRQ line coming back from the CC3100?

    Some documents (hint) it goes high when the CC3100 has completed processing the frame.
    I can't find a really solid definitive reference stating this, but some of the SPI wave-forms indicate this.

    If you capture this on your bus analyzer and see it going high around 20 microseconds after the end of your SPI transfer, that may confirm this.
  • Hi,

    according to the following Wiki-Link, this line is used by the CC3100 to indicate to the host, that is has something to communicate.

    I am not sure if it also applies, if you try to send consecutive SPI-Frames to the CC3100.