• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 43 subscribers
  • Views 161 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.

CC3220SF: I2C lock-up

Diego Lewis
Intellectual 1540 points
Part Number: CC3220SF
Other Parts Discussed in Thread: SYSCONFIG

Hi Team,

One of my customer is having some issues bringing up the CC3220SF per below. Please let me know your thoughts. 

I’m using the CC3220SF to interact with a I2C slave device.
To understand how to use the I2C library in TI, I run the sample code: i2ctmp_CC3220SF_LAUNCHXL_tirtos_ccs and it worked fine, I saw the values from the TI sensors.

After it, I connected the CC3220SF to our device that works on 3.3V (In TI, I connected the data to J16 and clock to J15).

Then I wrote my code, based on the sample, to write 11 bytes to our device – I2C slave.

The whole time I got the following error: “I2C bus is already in use!” when run the command I2C_transfer. Although when I debug the I2C device with Aardvark I see that our device works fine and there is no other master taking the bus.

I wanted to recheck the library, so I returned the jumpers to the place and run again the sample code: i2ctmp_CC3220SF_LAUNCHXL_tirtos_ccs. I still got : “I2C bus is already in use!”.
I didn’t success to do it work.

Any ideas on what could be going wrong here? 

Regards, Diego

  • 0
    TI__Mastermind 40965 points

    Hi Diego,

    What settings do you have in sysconfig for the I2C peripheral? If you can share an image of what you are using that would be good.

    Also, do you have pullups on the I2C lines when you are connected to your I2C slave? The jumpers that you are using, J15 and J16, are you connecting your I2C slave directly to pin2 of those jumper (the side connecting to the CC3220)? If so you will need to provide the pullups.

    Finally, for your test where you run the sample code again, do you perform a hard reset of the board before you re-run your code? Some peripherals such as the I2C bus can potentially not be fully reset solely by the MCU reset that is performed by the debugger.

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 10 points

    Hi Michael, 

    I had the problem described by Diego.

    I connected the I2C slave directly to the pins J15 and J16. Can I get the schematics for connecting the pullups?

    Before rerunning the sample again I performed a hard reset, but I still got the problem. 

    Thanks

    Ariel

  • 0 in reply to Ariel Frumkin
    TI__Mastermind 40965 points

    Hi Ariel,

    The CC3220 launchpad schematics can be found here; https://www.ti.com/lit/zip/sprcag0

    On page 5, there is a diagram of the I2C signal routing on the CC3220 launchpad. I've copied the relevant parts here:

    The pullups are after the J15,J16 jumpers, so you will need to keep those connected. If you keep the jumpers in place while having your I2C slave connected, are you still seeing the same issue?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Prodigy 20 points

    Hi Michael, 

    Thank you for your quick answer. 

    I didn't try to connect our slave device when the jumpers are in place. 

    But actually when I keep the jumpers in place and run the I2C sample "i2ctmp_CC3220SF_LAUNCHXL_tirtos_ccs" I got the same problem. 

    Thanks

    Ariel

  • 0 in reply to Benjamin Ariel Frumkin
    TI__Mastermind 40965 points

    Hi Ariel,

    If you have jumpers J15 & J16 connected then the i2ctmp example should run correctly. As this may be a hardware issue with your launchpad, I have assigned this thread to a member of our hardware applications team.

    Please give them 1-2 days to review and provide suggestions on your issue. We appreciate your patience in waiting for a response.

    Regards,

    Michael

  • 0 in reply to Benjamin Ariel Frumkin
    TI__Mastermind 46181 points

    Hi Ariel,

    Please probe the I2C lines with an oscilloscope and provide captures of the signal when you run the i2c example code.

    If the I2C clock is low, it may be stuck. The I2C slave device work as state machines and may be blocked if the CC3220 was reset before sending a stop condition.

    If this is the case, an easy solution you can implement is to toggle the clock multiple times before doing any I2C operations after the CC3220 powers up. 

    BR,

    Seong