• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 411 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.

CC2480 SPI Below 100 khz May Cause Timeout

sbeaman
Prodigy 60 points

It appears if you use an SPI rate below 100khz the CC2480 resets. I am guessing a  time out is happening.

Here is what happens:

1) Set SPI to 1 khz. (Note: any value below 100 khz seems to cause the issue).

2) Reset the CC2480

3) Host waits for SRDY to go low.

4) CC2480 sets SRDY low

5) Host Sets MRDY and SSEL low.

6) Host Sends Poll command (three zeros).

7) Host waits for SRDY to go HIGH.

8) CC2480 sets SRDY HIGH.

9) Host reads the AREQ message. (SYS_RESET_IND)

10) During the reading of the MINOR_REL value of the SYS_RESET_IND message the CC2480 sets SRDY low again. (I am guessing it reset itself and is notifying about a new SYS_RESET_IND message).

11) Any further commands the CC2480 appears to ignore. Since SRDY went low during the transmission/reception of a byte the host and CC2480 are out of sync concerning the state of the SPI.

As long as the SPI rate is 100 khz or above, everything works great.

I can not find anywhere in the API documentation that mentions a minumum SPI rate. Only a maximum rate of 4 MHZ.

  • 0
    Intellectual 330 points

    sbeaman said:

    It appears if you use an SPI rate below 100khz the CC2480 resets. I am guessing a  time out is happening.

    Hi sbeaman,

    what kind of hardware do you use? Are there any components connected to MOSI, MISO or CLK?

    Maybe a capacitor is in between?

    regards,

    OZ

     

  • 0 in reply to OZ2550
    Prodigy 60 points

    The host is an ARM7 (lpc2102). Tests were done both with hosts Hardware SPI and Bit Banging SPI.

    MOSI and MISO are direct connects with no additional hardware.

    SSEL, MRDY, and SRDY are direct connects with 10k pull up resistors.

    CLK goes through a 33 ohm resistor and has a 10k pull up resistor.

    No data lines have capacitors. Power lines (+3v3,+1v8) have bypass capacitors.

    Looking at the signals in the scope they have well formed edges and appear as you would expect.

    It just appears there is a maximum time allowed for the spi transaction to occur. If I am wrong I apologize,  but every test I have done so far seems to point to it.

    I can reproduce the same symptom by using a faster SPI rate (1Mhz+) but using JTAG to single step through the transmission code, Making the SPI transaction take longer.

  • 0 in reply to sbeaman
    Prodigy 60 points

    Ok, After reading some other posts I think I have figured out the issue. From: http://community.ti.com/forums/p/1164/10747.aspx#10747    Dirty Harry wrote on 12-17-2008:

    "As for the watchdog, this is the only reason for it to expire: an SPI Transport transaction that takes more than 1 second to complete from start to end. UART Transport does not even enable the watchdog. An SPI Transport transaction includes when the slave sets its ready pin active low - if the master does not service that asynchronous transaction from the slave within 1 second, the CC2480 slave will reset by watchdog. Thus, when you are running a debugger on your master and stop or break to look at something in the middle of an SPI transaction, or the SRDY goes active while you are stopped, the slave will surely reset."

    This means once the CC2480 sets SRDY low you have 1 second to start and complete the SPI transaction. If your SPI transaction speed is low you can run into issues.

    In my case after I reset the CC2480 I did some other setup work then read the SYS_REST_IND message. With the slower SPI rate I hit the 1 second limit. The CC2480 reset it self while I was reading the SYS_RESET_IND message.

    Please add the one second limit to the API documentation, or at least an Errata. It is important, has software design impact, and the lack of this knowledge cost me four days of debugging.

    (Comment: As long as the CC2480 is getting a valid clock, SSEL, MRDY and is receving or sending valid data. There is no reason it should reset.)