2 Replies Latest reply on May 17, 2012 9:11 AM by anandsrinivasana_

    Wiggle I2C SCK when SDA is held low on FX2?

      Stop me if you're heard this one before. I need to fix a hardware issue in software. <G>


      I need to wiggle the SCK signal on a FX2 while the SDA line is being held low. I am assuming that SDA being held low results in BERR error status bit being set and no I2C data transfer occurs, thus no clocking to clear the stuck I2C peripheral. Since SDA and SCK are not also GPIO pins there seems no way to do this. Is there some double secret handshake way of getting SCK to give me some edges?





        • 1. Re: Wiggle I2C SCK when SDA is held low on FX2?





          BERR is not set due to SDA being held low. BERR is set when there is bus contention during the preceding transfer, which results when an outside device drives the bus when it should not, or when another bus master wins arbitration and takes control of the bus. Please excuse me if I misunderstood your problem Please clarify the issue that is seen.







          • 2. Re: Wiggle I2C SCK when SDA is held low on FX2?



            Excuse my incorrect assumption about the BERR caused by SDA being held low, is sure sounded like bus contention to me. I haven't worked on the firmware or driver for the FX2 project before now. I'm just trying to help the system recover when power fails in the middle of a transfer and the I2C peripheral is still, apparently, returning data and holding SDA low.


            The hardware problem is the power rail doesn't go below the threshold to reset the peripheral chip due to battery backup of other parts fo the system. If I can toggle the SCK line the peripheral is eventually satisfied and the bus is unlocked (SDA is released).


            I did't find anything in the data book about ways to use the SCK pin other than its normal I2C duties. Is there any way to toggle it, unofficially supported or otherwise?



            • 3. Re: Wiggle I2C SCK when SDA is held low on FX2?

              There is no hidden way to work around this scenario. The two ways I can think of are


              connect another GPIO to the line and have it configured as input (effectively tristating it so that it doesn't interfere with I2C communication). When this scenario occurs toggle it at the required frequency and unblock the line. BERR will clear when it sees the ACK, then you can communicate with the slave.


              use a GPIO to reset the slave when this happens.