• AVR Freaks

Hot!I2C problems in MZ rev B2 not A3

Author
jrmymllr
Super Member
  • Total Posts : 196
  • Reward points : 0
  • Joined: 2011/06/11 06:05:25
  • Location: MPLS
  • Status: offline
2020/06/01 18:10:22 (permalink)
0

I2C problems in MZ rev B2 not A3

I'm using a PIC32MZ2048EFG064, xc32 V2.40, no Harmony. 
 
I'm having some I2C problems. The PIC is an I2C master to a single device, a touch screen controller. Previous boards were built with rev A3 and have been working flawlessly. I built another board and the touch screen didn't work....exact same layout, exact same code. I verified no solder bridges, and continuity is where it should be. I have 2.2K pull-ups on both lines and they measure correctly. I swapped LCDs and I know the LCD touchscreen is good. Upon throwing the debugger on it I'm seeing that the I2C peripheral appears to stop working after setting the I2C5CON.PEN. The chip acting screwy is rev B2.
 
I found someone else having trouble with B2 parts despite having working code on A3:  
 
 
https://www.microchip.com/forums/m1103301.aspx
 
 
....but, the issue they seem to be having is based upon not clearing the lower bits of I2CxCON when the bus is disabled/enabled. I never disable the bus, and it's not clear that I'd have to.
 
First, I've avoided I2C until this, so it's not second nature like most other PIC peripherals. Since I'm not using an RTOS and can't have blocking code, I kick off a transaction like this from an interrupt the LCD touchscreen generates:
 
  I2C5CONbits.SEN = 1;
  step = 1;

 
Then in the I2C interrupt I have a switch statement that processes the entire transaction in steps so I'm not waiting in while() loops. The 'step' variable is to keep track of progress:
 
 switch(step)
 {

 case 1:
  I2C5TRN = ((0x38 << 1) | 0);
  step = 2;
  break;

 case 2:
  I2C5TRN = 0x03;
  step = 3;
  break;

 case 3:
  I2C5CONbits.RSEN = 1;
  step = 4;
  break;

 case 4:
  I2C5TRN = ((0x38 << 1) | 1); //Sends the slave address over the I2C line.
  step = 5;
  break;

 case 5:
  I2C5CONbits.RCEN = 1;
  step = 6;
  break;

 case 6:
  x = (unsigned int)((I2C5RCV & 0x0F) * 256);
  I2C5CONbits.PEN = 1;
  step = 7;
  break;
 
(the other steps omitted)
 
IFS5bits.I2C5MIF = 0;

 
Like I said, this worked perfectly on rev A3. Now on B2, it's not going past step 6 (case 6). There's over 30 steps to pull the LCD touchscreen coordinates and I didn't put it all here because it doesn't go further than this because the I2C interrupt stops firing. 
 
First, is there a better way to do this without blocking code? I'm ok with this method if it works on all the part revs. And second, why does the interrupt stop firing on rev B2 parts!? According to the errata, rev B2 should only have an issue for clock rates >400kHz. I was running at 333, but reduce it to under 100KHz for troubleshooting.
 
Am I doing something fundamentally incorrect?
#1

9 Replies Related Threads

    jrmymllr
    Super Member
    • Total Posts : 196
    • Reward points : 0
    • Joined: 2011/06/11 06:05:25
    • Location: MPLS
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/01 18:59:09 (permalink)
    0
    Same issue if I have a straight list of I2C commands, no interrupts. Gets stuck on the last statement:
     
      
         I2C5CONbits.SEN = 1;
     while(I2C5CONbits.SEN);
     I2C5TRN = ((0x38 << 1) | 0);
     while(I2C5STATbits.TRSTAT);
     I2C5TRN = 0x03;
     while(I2C5STATbits.TRSTAT);
     I2C5CONbits.RSEN = 1;
     while(I2C5CONbits.RSEN);
     I2C5TRN = ((0x38 << 1) | 1); //Sends the slave address over the I2C line.
     while(I2C5STATbits.TRSTAT);
     I2C5CONbits.RCEN = 1;
     while(I2C5CONbits.RCEN);
     I2C5STATbits.I2COV = 0;
     x = (unsigned int)((I2C5RCV & 0x0F) * 256);
     I2C5CONbits.PEN = 1;
     while(I2C5CONbits.PEN);

    #2
    ric
    Super Member
    • Total Posts : 28324
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: I2C problems in MZ rev B2 not A3 2020/06/01 19:17:38 (permalink)
    5 (1)
    You're not sending the required NACK cycle before sending the STOP.
    You need to set I2C5CONbits.ACKDT then set I2C5CONbits.ACKEN then wait for ACKEN to clear.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #3
    jrmymllr
    Super Member
    • Total Posts : 196
    • Reward points : 0
    • Joined: 2011/06/11 06:05:25
    • Location: MPLS
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/01 19:19:30 (permalink)
    0
    ric
    You're not sending the required NACK cycle before sending the STOP.
    You need to set I2C5CONbits.ACKDT then set I2C5CONbits.ACKEN then wait for ACKEN to clear.


    Ahh, ok I figured it was something simple. Strange this worked on the older rev part!
    #4
    ric
    Super Member
    • Total Posts : 28324
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: I2C problems in MZ rev B2 not A3 2020/06/01 20:07:12 (permalink)
    5 (1)
    Please confirm if that works. I'm just reporting what the datasheet says, I've never done I2C on that chip!
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #5
    Stefiff
    Senior Member
    • Total Posts : 99
    • Reward points : 0
    • Joined: 2012/07/15 15:26:29
    • Location: 0
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/02 03:28:22 (permalink)
    0
    Just a tip.
    Do not use this method if the software needs to work to ensure that it never crashes. This is done only for amateur things.
    If for some reason slave device keeps the signals at zero, then everything stops indefinitely, without any error flag. This is normal mode and allows slave to stretch the command until the device is ready. This detention can be of anything, even interference if you will. The slave just block/stop and your software will block also.
     
    The correct way is to start a timer with starting the command itself.
    How it should be.
    1/ Check for SDA and SCL. If not goto ERROR..
    2/ Start Timer
    3/ Start Command
    4/ Check end of command. If OK goto 7
    5/ Check Timer. If end goto ERROR..
    6/ Goto 4
    7/ Clear flags and return, command OK
     
    ERROR: reinitialize I2C module… restart/reset slave..
     
     
    post edited by Stefiff - 2020/06/02 03:30:26
    #6
    jrmymllr
    Super Member
    • Total Posts : 196
    • Reward points : 0
    • Joined: 2011/06/11 06:05:25
    • Location: MPLS
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/02 04:57:12 (permalink)
    0
    Stefiff
    Just a tip.
    Do not use this method if the software needs to work to ensure that it never crashes. This is done only for amateur things.

    This makes sense. Earlier on, I noticed communication would stop and I didn't know why. So I implemented a timer for the entire 35 step sequence. If it didn't get to the end before the timer expired, I would restart the process, but never reinitialized the I2C module. This took care of that problem and the two boards with the older rev part have been flawless for weeks.
     
    But now it reliably gets stuck when sending PEN, and is it because I'm not sending ACKDT and ACKEN as Ric suggested? I know I wrote the original code from an example somewhere as I couldn't come up with that myself due to my lack of I2C knowledge.
     
     
    #7
    Stefiff
    Senior Member
    • Total Posts : 99
    • Reward points : 0
    • Joined: 2012/07/15 15:26:29
    • Location: 0
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/02 05:28:34 (permalink)
    0
    Simply insert NACK before STOP.
    TP/touch panel/ usually have a RESET pin, so if TP block, just restart it.
    When really is not totally blocked slave, in 99% of cases, slave received +1 clock /interference, induction ../. It holds the lines because it doesn't know what to do. And then everything remains to wait indefinitely.
    #8
    jrmymllr
    Super Member
    • Total Posts : 196
    • Reward points : 0
    • Joined: 2011/06/11 06:05:25
    • Location: MPLS
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/02 12:47:16 (permalink)
    0
    Stefiff
    Simply insert NACK before STOP.
     


    Yep that was it. I'm still confused why rev A3 worked without that, but it seems I wasn't doing it correctly to start with. Hats off to you and ric.
    #9
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3992
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: I2C problems in MZ rev B2 not A3 2020/06/06 02:43:47 (permalink)
    5 (1)
    Stefiff
    Just a tip.
    Do not use this method if the software needs to work to ensure that it never crashes. This is done only for amateur things.
    If for some reason slave device keeps the signals at zero, then everything stops indefinitely, without any error flag. This is normal mode and allows slave to stretch the command until the device is ready. This detention can be of anything, even interference if you will. The slave just block/stop and your software will block also.
     
    The correct way is to start a timer with starting the command itself.
    How it should be.
    1/ Check for SDA and SCL. If not goto ERROR..
    2/ Start Timer
    3/ Start Command
    4/ Check end of command. If OK goto 7
    5/ Check Timer. If end goto ERROR..
    6/ Goto 4
    7/ Clear flags and return, command OK
     
    ERROR: reinitialize I2C module… restart/reset slave..
     



    Bad advice.

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #10
    Jump to:
    © 2020 APG vNext Commercial Version 4.5