problem regarding i2c communication on pic32

Discussion in 'Embedded Systems and Microcontrollers' started by In2Dusk, Oct 29, 2012.

  1. In2Dusk

    Thread Starter New Member

    Oct 29, 2012
    3
    0
    I have an IMU (MPU-6050) and PIC32MX120F032B, i would like to communicate between them using I2C,
    IMU is slave and it does not send ACK signal back. I have used modified pic32 i2c example code.
    I have 4k7 pull-up resistor on both SDA and SCL. Please post all your ideas and solutions.

    This is result of logic analyser during slave address (0b11010000) transmission: (upper - SCL, lower - SDA , I2CFREQ = 5000Hz)
    [​IMG]

    I am not getting ack back from slave. Please help me.
     
  2. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,386
    1,605
    I don't like how your START and STOP pulses look. Inside an I2C transaction nothing happens at the same time, no edge of SCL occurs with an edge of SDA. Unless this is an artifact of the logic analyzer fix that first.

    The address you send looks correct for AD0 = 0.

    That's all I see here.
     
    In2Dusk likes this.
  3. JohnInTX

    Moderator

    Jun 26, 2012
    2,339
    1,020
    Start and stoP look OK to me (first and last transitions on SCL occur when SDA=1). The address is 1101000 which corresponds to AD0==0 on the MEMs. Is CE/ correct on the MEMs for I2C?

    I agree with ErnieM, the SCL rise vs SDA fall are really close on some of the lines. I blew up the PNG and they still look close. Hard to tell from the logic analyzer though.

    Other than that, it looks like an unaddressed I2C slave to me. As ErnieM indicated, its probably time to drag out the scope and look at the actual rise/fall of SCL vs SDA and make sure they agree with the spec.
     
  4. In2Dusk

    Thread Starter New Member

    Oct 29, 2012
    3
    0
    Thank you for your quick replies! I made some changes to the code and i was able to receive ack signal after sending slave address, but when i try to send anything after it, i dont get ack back.
     
  5. JohnInTX

    Moderator

    Jun 26, 2012
    2,339
    1,020
    Presumably, you got the SDA/SCL edge times a bit further apart, yes?

    So, does it NAK on the next byte sent? If so, you should be able to see the byte in the clock and data with NAK on the 9th clock. What happens then? The master should see the NAK and send the stoP condition. Does it? If so, at least the master is happy with the bus signals.

    As to why the slave NAKs, is it happy with the data? If not, maybe its telling you by NAKing. That's its way of telling the master to shut up.

    Since it looked like the timing was a bit tight, take a good look at the first ACK. On this bit, the master releases SDA then generates one clock then grabs the bus again for the next byte (or stoP). In this period, SDA can spike around (e.g. master lets go of SDA before the slave grabs it. The same can happen on the end of ACK/NAK). If SCL timing is too close to this, the slave can perceive it as a stoP (or even rS) condition and bail out. Seen it happen before. Also check for ringing on SCL/SDA etc that may generate false edges that look like stoPs.

    Are you bit banging this?

    BTW: if you are going to be doing a lot of I2C, you might want to get one of these or something similar. It will catch timing and protocol issues both. I love my Beagle.
     
    Last edited: Oct 29, 2012
    In2Dusk likes this.
  6. In2Dusk

    Thread Starter New Member

    Oct 29, 2012
    3
    0
    I send slave address and my chip reads ack back, then i send register address (WHO_AM_I register, 0x75) and i get nack, but when i look at signal with logic analyser i see that slave have not even acked slave address.

    I am using hardware i2c of pic32mx120f032b for communication.

    (i2c freq = 5kHz, upper - SCL, lower - SDA)
    [​IMG]
     
    • i2c.png
      i2c.png
      File size:
      5.6 KB
      Views:
      142
  7. JohnInTX

    Moderator

    Jun 26, 2012
    2,339
    1,020
    What's that glitch at the red cursor? Don't like it.

    What is the actual sampling rate of the logic analyzer compared to the I2C setup / hold times in the spec? As displayed, the width of the trace is many times the I2C limits. You might be missing something down at the 10ns - 100ns ranges that characterize some I2C timings.

    You said that you were getting an ACK after the address but now you aren't.. Did you see it on the analyzer or read it from I2CxSTAT,ACKSTAT? I ask because usually, whenever a slave NAKs, the master is supposed to stop transmitting and generate a stoP condition. Its not doing that. I'm not real up on the P32 I2C or what you are programming with (C library etc) .but it should accommodate this via status line that the firmware reads or do it automatically.

    SDA and SCL are still pretty close together. Have you looked at it with a good DSO to make sure SDA is stable before SCL rises? No glitches? How about the setup and hold times? A fast DSO with a long record memory in a peak or glitch detect mode will show you things that your logic analyzer will miss. Which analyzer are you using? Some of the low cost or freebie PicKit ones are nice to have but are not really up to hardcore bus analysis. The Beagle is a great tool. I've used it on a bunch of I2C, some behaving badly, and its only once had trouble with not being able to diagnose bus hardware problems. That time was when SCL and SDA were occasionally coincident on a high speed, multi-master bus. It reported a problem OK but couldn't figure out what it was. It took lots of scrolling DSO captures to find it.

    So two main things:
    The slave does not think its being addressed so is never asserting NAK on SDA. Your waveforms are consistent with a slave that is completely off line. Wired correctly?

    The master should detect the first NAK, abort the transmission and send stoP. You can debug this without any slave attached. Just send Start, some address and the master should send stoP after the 9th clock. When that works, connect a slave and make sure it continues to do that when you see it on the analyzer. If it continues to send after you see a NAK, the master is confused. If you're working in MPLAB, set a breakpoint after the Start+address sequence is complete (as indicated by SSPxSTAT,TRSTAT. Then look at ACKSTAT and make sure the code handles NAK and hopefully, eventually ACK, correctly). Also, inspect all of the other status bits and make sure they are consistent with what the analyzer says happened on the bus.

    If everything looks like it should work, try another I2C device like a serial EEPROM and see if you can read/write to it.

    Good luck.
     
    Last edited: Nov 1, 2012
    In2Dusk likes this.
Loading...