• AVR Freaks

Hot!Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144?

Author
Alex M.
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2019/06/28 10:53:38
  • Location: 0
  • Status: offline
2019/06/28 14:08:47 (permalink)
0

Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144?

We released a custom controller board, powered by the PIC32MZ2048EFH144-I/PL, to production back in February of 2017.  Our firmware hasn’t change since the release and has worked on Silicon Revisions A1 & A3.  We have just received our first batch of Silicon Revision B2 chips which should have fixed the previous issue with the I2C (according the the current errata), but instead it has cause our code to stop working.  We have two device on the I2C bus, a Microchip P/N:24AA044 EEprom and a Maxim P/N:1631 High-Precision Digital Thermometer.
 
Anyone else having issues with I2C on the new B2 silicon?
#1

14 Replies Related Threads

    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/08 10:53:21 (permalink)
    0
    Just wanted to update...
    We definitely seem to be having I2C issues with the new B2 silicon revision parts.  We took one of the non-functional board with the B2 Silicon part, removed and replaced it with an old A1 silicon part we had and now the board is working perfectly.  The only change was the B2 to A1 silicon IC change.
    #2
    ric
    Super Member
    • Total Posts : 23536
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/08 15:29:13 (permalink)
    0
    Which I2C peripheral are you using?
    The errata sheet indicates that I2C3 is totally missing in revision A3.
    (I recall reading that they "stole" some of the logic from I2C3 to try to fix I2C1 and I2C2.)
    It seems to indicate that everything should work in revision B2, but you could be the guinea pig...
     

    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
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/08 16:02:43 (permalink)
    0
    Hi Ric, thanks for the response.  It sure feels like I'm being a guinea pig right now.  As I mentioned previously we haven't had any issues with silicon revisions prior to B2.  We have boards functioning perfectly with revisions A1 & A3. 
     
    Up until today we were still questioning if it was the newly built fabs or the ICs which were causing the problem.  Today we received one of the new boards (originally with B2 silicon) back from rework with an A1 silicon part installed instead.  This board previously was non-functional and now works fine, so it's got to be an issue with the new B2 silicon parts. 
     
    We are currently communicating with a Microchip (P/N:24AA044) Eeprom on our custom board, and 0-2 more off board depending on the product.  We also have a Maxim (P/N:1631) High-Precision Digital Thermometer off board as well.  We are using SCL1 & SDA1 on pins 95 & 96, so I believe these are I2C1.  Also, regardless of if the off-board devices are connected or not the B2 silicon will not communicate with anything.  We are just getting time-outs. :(
     
    Thanks,
     
    Alex
    #4
    NKurzman
    A Guy on the Net
    • Total Posts : 17708
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/08 17:55:32 (permalink)
    0
    1. Have You contacted Microchip?  You need to put in a Support Ticket.
    2. Have you attempted to debug the Issue?  There could be a Bug in you code the the old silicon was not bothered by.
    3. What Bus Speed?
    4. "We are just getting time-outs" does that mean something?  what is timing out? the Start bit?  what time are you allowing?
    5. What is the State of the I2C Bus when the PIC "fails"
    6. Are you saying you get the fault when Only the EEPROM is connected?
    7. Does it work, then fail, or never works?
    #5
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/09 16:28:40 (permalink)
    0
    Thanks for the reply!  I should have mentioned some of those details earlier but forgot. So here it goes:
    1. Yes, I filed a ticket with Microchip on June 27th about 10am PT.  I then called into the system with my phone access number, waited on hold for a while and then finally decided to use the call back system.  Unfortunately I waited all day for a call back but never got one.  Then on Friday the 28th, I get an email from Client Development about my case asking for:
    Program name (End Product):
    Application:
    Parts used: (Full part number):
    Expected annual usage (EAU):
    Design Stage:
    I had already provided most of this information so I wasn't sure why it was relevant and needed.  In my correspondence I made sure to inform them that I was going to be out the week of the 1st and to CC my coworker on any and all correspondence.  They said they would forward the information to tech support and assign it to an engineer.
    After the lack of response on Thursday and the email I received on Friday, I decided to try these forums to help.
    On Monday the 1st, I received an voicemail from my case tech support, who said he was looking into and would post anything he found to my case.  My coworker was forwarded this voicemail but found nothing in the case.  I got back yesterday, and called in but my tech support person was out on vacation.  I have finally been in touch with my case tech support person at Microchip today, and I provide as much more information as possible, but am still waiting on feedback. 
     
    2. Yes, we have tried some debugging however this issue couldn't have come at a worst time.  Our software programmer (the author of this code) retired about a month ago and our new software programmer doesn't have experience with firmware coding.  I am the electrical engineer and designed the hardware but did not code the software.  I am trying to ramp up as fast as possible, but my understanding is not the best.
     
    3. We are running the I2C at 50kHz.
     
    4. We are getting a timeout error 21, from the best I can see this is the Start bit time out. See code below:
    /******************************************************************************
     * Function Name: I2C_MasterWriteRead
     * Description: Performs a Write followed by a Read of the I2C Port
     * Parameters: uint8_t - slave_address
     * Returns: 0 if completed with no errors, or an error code where the error
     *          occurred.
     ******************************************************************************/
    int16_t I2C_MasterWriteRead(uint8_t slave_address)
    {
        int16_t retResults = 0;
        
        /* Put module in master TX mode (generates START) */
        I2CCONbits.SEN = 1;

        // Wait for SEN to Clear
        StartI2CTimerSingleClock();
        while (I2CCONbits.SEN && !I2CTimerExpired());
        if (I2CTimerExpired())
            return 21; // Signal time out error

     
    5. I'm not exactly sure how to answer this.  The bus seems to be operating normally however none of the device on the bus seem to be able to communicate with the PIC.
     
    6. Yes, this lack of communications occurs when only the eeprom is on the bus.  I have also tried with only the thermometer and it still can not communicate.  All combinations of devices on the bus have the same issue.
     
    7.  It seems to never work.
     
    Any thoughts or things to try would be greatly appreciated!
     
    Thanks,
     
    Alex
    post edited by Alex M. - 2019/07/09 16:34:56
    #6
    ric
    Super Member
    • Total Posts : 23536
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/09 16:37:09 (permalink)
    0
    You need to single step your code with the debugger, and see what the SCL and SDA pins do once the I2C module is enabled.
    They should both be floating high, if not, you need to find out why.
    e.g. what happens if you just set them both as inputs, and do NOT enable the I2C module?
    Is it any different if you disconnect the Maxim part?
     

    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!
    #7
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/09 17:20:58 (permalink)
    0
    Hi Ric, Thanks for the reply.  I am currently testing with just the one eeprom on-board and the Maxim part disconnected which makes no difference.  I will try to step through the code tomorrow with the software engineer but can't right now.  I don't think there is anything on the bus holding them low (or high other than pull-ups) due to the scope captures I have.  After your question I have noticed something I hadn't before so thanks for question and getting me to see the difference, it might be a clue.  Below are the captures I have, one of the bad board and one of the good board.  During power up the initial activity will be a read/write of each device to discover if it's on the bus.  After that is the polling of the devices.
     
    Here is the first few seconds of the I2C lines on Bad CPU from Start Up (#1 - SCL1, #2 - SDA1)
     
     
    Here is the first few seconds of the I2C lines on Good CPU from Start Up (#1 - SCL1, #2 - SDA1)

     
    Here are the I2C lines on Bad CPU from Start Up Zoomed to beginning of data (#1 - SCL1, #2 - SDA1)

     
    Here are the I2C lines on Good CPU from Start Up Zoomed to beginning of data (#1 - SCL1, #2 - SDA1)

     
    What I had previously noticed is that the data line on the bad board goes high on each clock group after the third group but on the good board the data line seems to actually present data and not just stay high.
    What I hadn't noticed is that during initial start both lines are pulled high via the pull-ups.  However afterwards on the bad board, the clock high and the data is low between drives of the lines and on the good board, the clock low and the data is high between drives of the lines.
     
    Thanks,
     
    Alex
    #8
    ric
    Super Member
    • Total Posts : 23536
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/09 17:41:00 (permalink)
    0
    I'd be testing it without any other I2C devices connected. It still looks like something else pulling data low.

    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!
    #9
    Antipodean
    Super Member
    • Total Posts : 1732
    • Reward points : 0
    • Joined: 2008/12/09 10:19:08
    • Location: Didcot, United Kingdom
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/10 08:40:32 (permalink)
    0
    ric
    I'd be testing it without any other I2C devices connected. It still looks like something else pulling data low.



    But that doesn't explain why it works with a previous revision chip.
     
    It does seem to me that he has done sufficient testing to show that there is a change in the CPU peripheral somewhere that causes the data line to be held low between clock bursts which definitely shouldn't happen.

    Do not use my alias in your message body when replying, your message will disappear ...

    Alan
    #10
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/16 13:17:37 (permalink)
    0
    Thanks for all the comments and thoughts so far.
     
    I have been working to better understand the fault we are seeing with the B2 silicon parts. From the hardware side I have pinpointed the fault location and the messages up to the failure.
     
    Attached is the "Good vs Bad Messages.png", this file has a side by side of the B2 (Bad CPU) and A1 (Good CPU) messages being sent with scope captures. The first thing we do with the I2C is write & read the eeprom(s). The fault occurs at the end of the first read of the eeprom. The A1 silicon finishes properly with a NACK at the end of the read data (and continues), but the B2 silicon ends the read data with an ACK, then kind of goes crazy after the next stop & start are sent with the clock going from 50kHz to approximately 6.75kHz.  I'm scratching my head and have no idea what's going on.  The hardware is definitely interpreting the code differently.  I'm going to continue and track down exactly where in the code it goes crazy and then try to get the before & after I2C registers to see what's happening.
     
    If any of this points to anything, please let me know.  Without the software engineer that wrote the code I (the hardware guy) and the new software guy are learning as we dig.  Thanks!

    Attached Image(s)

    #11
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/23 12:50:14 (permalink)
    5 (1)
    It seems we have discovered our problem(s).  There seemed to be several bits of code that process differently between the A1, A3 revisions versus the B2 revision.  The heart of all our problems however seems to be the way the B2 revision handles the stop bit after a command.  After our read / write commands we disable the I2C bus, check for a stuck low data line, and then enable the I2C bus again.  With the A1 & A3 revisions of silicon after the enable command, the I2C bus comes up in idle and having I2C1CONbits<4:0> clear (all zeros).  However on the B2 revision silicon after the enable command, the I2C bus comes up with the I2C1CONbits.PEN = 1.  We thought this bit was supposed to clear itself or at least be cleared upon enabling / re-enabling the I2C bus but this doesn't seem to be the case.
    #12
    steverap
    Super Member
    • Total Posts : 157
    • Reward points : 0
    • Joined: 2003/11/07 12:38:54
    • Location: San Jose, CA, USA
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/23 16:03:55 (permalink)
    0
    Since the I2C didn't work correctly prior to Rev B2 (without bit-banging), I'm not surprised that the code you used on the A1/A3 part doesn't work on the B2 part. I am using the Harmony I2C library, and the I2C ports are working fine at 400 kHz.
     
    To ensure we received the Rev B2 part,  we had to order PIC32MZ2048EFM144-I/PHN23, and unfortunately you have to order them in quantities of 90.
    #13
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/07/23 16:12:51 (permalink)
    0
    Actually the I2C worked fine on the A1 & A3 revisions without bit-banging as long as you stayed below 100kHz, per the errata.  We ran at 50kHz and therefore never had any issues.  The "fixes" to the I2C shouldn't have changed this in revision B2 regardless of bit-banging or not.
    #14
    Alex M.
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/06/28 10:53:38
    • Location: 0
    • Status: offline
    Re: Anyone else having I2C issues with the B2 revision silicon of the PIC32MZ2048EFH144? 2019/08/23 16:18:20 (permalink)
    0
    Just wanted to post a link to my other thread where I have figured out the issue.  Hope this can help others.
    https://www.microchip.com/forums/FindPost/1110029
    #15
    Jump to:
    © 2019 APG vNext Commercial Version 4.5