• AVR Freaks

Hot!MCP2221A: stuck SDA line

New Member
  • Total Posts : 1
  • Reward points : 0
  • Joined: 2020/01/15 08:22:16
  • Location: 0
  • Status: offline
2020/01/17 06:03:26 (permalink)

MCP2221A: stuck SDA line

I'm requesting some help with the MCP2221A USB-I2C converter.
We have designed a dedicated card with the MCP2221A communicating over I2C with 5 slaves, of 2 different types.
After several hours of functional I2C communication (~4 to 10 hours), it seems there is issue during the I2C transfer. We are not able to observe the issue with an oscilloscope, but the result is the SDA line being hold at low level. We are not sure about the root cause, but it seems one of the slaves is holding SDA, as a MCP2221A reset would not release SDA.
When this issue occurs, the MCP2221A does not communicate anymore because we can't observe any changes on the SCL line.
The solution for our problem would be the MCP2221A to generate pulse on the SCL line to unlock the faulty slave and release the SDA line.
Is there a way to have the MCP2221A unlock the situation by:
- generating a pulse on SCL line
- manually controlling the SCL line
- launching a recovery mechanism
We have tried sending an "I2C Write Data (0x90)" command but it is not sent and the SCL signal does not change when the SDA is stuck.

Thank you for your help

2 Replies Related Threads

    Super Member
    • Total Posts : 25592
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: MCP2221A: stuck SDA line 2020/01/18 01:57:21 (permalink)
    +1 (1)
    When your code does a READ transfer, does it ACK every received byte EXCEPT for the last one?
    It is imperative that you send a NAK in response to the last byte of the transfer, just before you send the STOP cycle.
    If you don't, the slave thinks you want to receive more data, and will start driving SDA low if the MSB of the next data bit is low.
    As you have seen, the only way to clear the bus is to toggle SCL nines time without the Master driving SDA, then send a STOP cycle. I have no idea if it's possible to do that via the MCP2221A, I've never used it.
    (If I'm mistaken, and all this is handled inside the MCP2221A, then maybe something is resetting the MCP2221A part way through a read transfer, which would cause the same problem)
    post edited by ric - 2020/01/18 01:58:28

    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!
    Super Member
    • Total Posts : 3642
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: MCP2221A: stuck SDA line 2020/01/18 09:27:09 (permalink)
    The MCP2221A seem to be a PIC microcontroller preprogrammed with USB, UART, I2C and GPIO.
    PIC16(L)F1455  seem to have the same footprint and peripherals. 
    In addition to I2C there are also 4 GPIO pins that may be controlled from the PC and USB connection.
    In the GUI Terminal application, there are settings to write and read these GPIO pins.
    This may lead to a quite convoluted workaround:
    By connecting 2 of the GPIO pins to I2C SDA and SCL pins, it may be possible to make signals that cannot be made by I2C peripheral hardware.
    For the GPIO pin that is connected to SCL signal,
    give alternating commands between Write Low, and Read Input.
    Reading the GPIO should allow Pull-up resistors on SCL line to make High clock signal.
    Repeat 9 times. During this sequence, it may be possible to observe SDA line changing.
    SDA line should end at High logic level.
    Then make a Stop signal sequence this way:
    Write  both GPx-SCL and GPy-SDA  Low, then Read GPx-SCL only, and then Read Both lines together.
    If there is one millisecond between each USB transfer, then additional delay may not be needed,
    or 1 millisecond delay may be specified between each transfer.
    I assume that any command given thru the MCP2221 I2C/SMBus Terminal application,
    also may be programmed using the DLL driver interface.
    Another Question: What are the actual I2C Slave device types used?  
    Many I2C Slave devices are available  in both I2C and SMBus variants.
    If you may be able to change to SMBus compatible slave devices,
    then it may be possible to avoid such stuck bus conditions,
    since SMBus slave devices shall have hardware timeout to prevent such state.
    Jump to:
    © 2020 APG vNext Commercial Version 4.5