1 Reply Latest reply on Jun 24, 2017 5:18 AM by graa

    I2C basic - trying to analyse the signals without slaves




      I am using the 4200 BLE pioneer kit board to interface an external FRAM chip (not the one on the board itself). Since it works little bit different I will understand the I2C protocol and try to analyse the signals with a logic analyser.

      As a base project I use the simple fram test project from this topic http://www.cypress.com/forum/psoc-4-ble/fram-ble-pioneer-board-and-i2c.
      This project works as expected with the onboard Fram chip (pins 5.0 SDA and 5.1 SCL), so I know the I2C component is properly working as such.  The program tries to write to and read from FRam every second.
      Now I map other I2C capable pins to drive an external I2C bus. There are no slaves on the bus and each line is pulled up by a 2K resistor to ca. 3.3 V  (voltage divided from 5 V). Each line has a logic analyser probe attached and I do not see any activity on the lines. SCL is always low and SDL always high.
      Shouldn't there be at least START sequences from the master?
      When I attach a slave though, I can see full communication. Is this the expected behaviour?

        • 1. Re: I2C basic - trying to analyse the signals without slaves

          I checked the project you are using.  In the project, the Fram_Write function first calls the Fram_SetAddress function that sends the start condition followed by the slave address.  It then checks if the slave sent an ACK.  If no ACK was sent, it returns with this status and the Fram_Write function does not continue anymore.  The code does not handle an error condition when a slave is not present.  With proper error handling implemented, the Master should send a stop to reset the I2C bus back to it's default state which is both SCL and SDA at HIGH.  As this is not happening, you are seeing SCL stuck at low.  With this condition, all further calls to the Fram_Write function will also not execute.  When a slave is present, everything works normal.


          So, this is an expected state considering how the code handles an absent slave.