I have come closer to understand why my Raspberry PI (acting as I2C master) does not see my I2C slave (on my startkit).
With the help of the simulator I am able to get the slave to make an ACK when matching address is sent first. If I instead send another address as first address will it not ACK on any of the following attempts and this is what the raspberry does when it runs the i2cdetect code (it starts with address 0x03 and continues forward with all addresses)
Also, once the slave as made an ACK will it not ACK again even if same address is sent again but maybe this is according to specification.
Attaching images showing the issue.
I have also tested with real HW and where I set my startkit to have address 0x03 (The first address sent by the PI master) and there one can see that the slave does an ACK but it keeps holding the SDA low as seen by the attached images:
Any comments on this before I start to investigate why this is the case?
/Igor
I2C slave only works if it gets match on first address
-
IgorLopez
- Member++
- Posts: 25
- Joined: Tue Mar 11, 2014 8:16 pm
I2C slave only works if it gets match on first address
You do not have the required permissions to view the files attached to this post.
-
larry
- Respected Member
- Posts: 275
- Joined: Fri Mar 12, 2010 6:03 pm
Is this using the latest I2C library (I think it's version 3.1.1)?
Two consecutive commands with the same address should either be both ACKed or both not ACKed. This could be a bug. It should be easy to see in the source why that would be.
Slave should release SDA at the end of the 9th cycle, so that could be a bug as well. In the code you can add a breakpoint or print where the SDA port is turned around to input direction using the ":>" operation, which tristates it.
Two consecutive commands with the same address should either be both ACKed or both not ACKed. This could be a bug. It should be easy to see in the source why that would be.
Slave should release SDA at the end of the 9th cycle, so that could be a bug as well. In the code you can add a breakpoint or print where the SDA port is turned around to input direction using the ":>" operation, which tristates it.
-
IgorLopez
- Member++
- Posts: 25
- Joined: Tue Mar 11, 2014 8:16 pm
Yes, it is version 3.1.1 I am using.
I am currently trying to understand the i2c_slave statemachine but have not fully grasped it.
The state names and call back names are a little bit confusing with respect to if master is writing to slave or if master is expecting to read from slave.
In state ACK_ADDR is next state set to MASTER_WRITE (I have renamed to WRITE_TO_MASTER) when slave has ACK and R/W bit is set high (master request for data read from slave)
If R/W bit is set low then is next state MASTER_READ (which I renamed to READ_FROM_MASTER).
When checking those states it is a mismatch, e.g. in MASTER_READ is the slave trying to write to MASTER and in MASTER_WRITE is the slave reading the data on sda written by master.
I am currently trying to understand the i2c_slave statemachine but have not fully grasped it.
The state names and call back names are a little bit confusing with respect to if master is writing to slave or if master is expecting to read from slave.
In state ACK_ADDR is next state set to MASTER_WRITE (I have renamed to WRITE_TO_MASTER) when slave has ACK and R/W bit is set high (master request for data read from slave)
If R/W bit is set low then is next state MASTER_READ (which I renamed to READ_FROM_MASTER).
When checking those states it is a mismatch, e.g. in MASTER_READ is the slave trying to write to MASTER and in MASTER_WRITE is the slave reading the data on sda written by master.