• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 638 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.

CC8520 under PPWC with I2C pull-ups, no codec

Oleg Komlev
Expert 1740 points
Other Parts Discussed in Thread: CC8520

Hi everyone,

We're using Anaren's CC8520-based module soldered on custom board and do some link budget testing. We use PPWC - flashing slave_p.hex in and using RX/TX test.

For now, we have no codec connected to 8520 via I2C. SDA/SCL line were left floating. Then we've noted CC85xx datasheet (and consequently Anaren manual) states that SDA/SCL must be connected to external pull-up. Indeed, on PurePath EB there are a couple of 2.7k resistors pulling SCL/SDA to 3.3V.

However, when we pull SDA/SCL pins up without having actual I2C connection to codec, the CC8520 fails to reply to SPI commands from CC debugger. Command log shows either "RF device not ready" (after trying chip reset), or reports SPI errors and blank SPI responces. When powered up, 8520 immediately begins transmitting both clock and data on SCL/SDA, and stops doing this once SPI error happens. Removing pull-ups solves the problem immediately.

We are very curious about this behaviour. I've seen a thread here where it was stated that 8520 could hang when trying to connect to nonexistent I2C slave, and PPWA EB does have codec installed (thus not susceptible to this). 

So the question is:

Is it mandatory to have powered-up codec connected to I2C bus when SDA/SCL are pulled up, or should those pull-ups be there regardless? 

tl,dr: guys (and ladies), I've pulled up unconnected I2C pins of 8520 with 2.7k resistors to 3V, and now 8520 bangs out I2C packets continously, seemingly ignoring EHIF commands.

 

Any input is very welcome.

  

Thanks,

Oleg 

  • 0
    TI__Expert 7160 points

    Hi Oleg,

    This is strange behaviour I think. You should be able to program your devices with the CC Debugger even when an expected I2C slave is missing. For example when I remove the jumper block on P15 on the PPW Audio EB I disable the power to the onboard aic3101 codec. But I am still able to program the CC85xx, even though it is constantly trying to connect to the non-existing aic device. The pull-ups are present, but the I2C slave is not.

    But to eliminate the problem completely you should try to select DSP as the audio device when making your production test image. Then the CC85xx will not attempt to communicate to any I2C slave, and the I2C interface can be left floating.

    Best regards

    Kristoffer

  • 0 in reply to Kristoffer S
    Expert 1740 points

    Hi, Kristoffer

    Thanks for your answer.

    I forgot the important part - I was actually able to program CC8520 without any problem, no matter with or without I2C pullups.

    The problem appeared only when I've tried to use Wireless Commander for some RX/TX tests (we were estimating link budgets for Anaren's modules compared to TI's reference design). The device was flashed with slave_p.hex image for test. With I2C pullups and without codec, RX/TX settings and "Start" button were simply missing, and command log stated either zeros returned by SPI slave (i.e. 8520) or "RF device not ready" status. Admittedly, it didn't come to me to flash CC8520 with something like demo application to check how will device boot with and without codecs configured, I'll do it ASAP. The slave_p.hex image itself is not corrupted.

    Without pullups, the RX/TX window was like it should be (which apparently means CC8520 was able to boot and respond to commands from CC debugger). 

    Another problem that we've had is fragile SPI link during RX/TX rest. E.g. RX test makes use of RSSI report command, and once in a several dozens of requests, CC8520 would return zeros. This problem is completely specific to our custom boards. The intermediate cable between CC debugger's ribbon cable and SPI slot located on board is approx. two inches "spaghetti-type" (basically a bundle of wires) and is unshielded. When connected by this cable and running RX/TX tests, CC8520 shows rather violent noises in digital signals (up to 300mV) and up to 100 mV of ground bounce (we've had two custom boards with somewhat different decoupling, but in general this problem does not exhibit itself when host is connected to 8520 instead of CC debugger). The CC8520s are flashed without problem, though.

     

    BR,

    Oleg