[SOLVED] Fail establishing I2C communication

Status
Not open for further replies.
Joined
Sep 11, 2023
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
21
Hello,

I am trying to create an I2C communication between an arduino mega and an ATMEGA1284p.

The arduino is programmed using the arduino IDE (see atttached) and is the master.
The ATMEGA1284p is programmed using Microchip studio (See attached) and is the slave.

The SDA and SCL line are displayed on the attached SDA_SCL attached file (SCL in blue).
They show the address the master sends to the slave.

The address seems correct (0x20).
But there is no reaction from the slave.

The code of the slave is very simple.
It is just supposed to turn a LED on when it recognized it has been addressed. i.e. after the line

while(!(TWCR&(1<<TWINT)));

However, the slave code never goes beyond this line and the LED never turns ON
On the hardware side, SDA and SCL lines have each a pull-up resistor 2.7kOhm.

Ii would be very gratefull if you could help me finding the issue.

Thank you very much
Best regards
Benjamin





 

Hi,

What worries me first:
Why are there 9 clock cycles in the scope picture. I expect 8.

Did you notice, that you say Address is 0x20 but the sent data rather is 0x40?

One possible problem is that there are different interpretations of the address.
Some say: 0x20 --> 0b 0010 000r (r = RW bit. RW bit ORed to the 0x20)
others say: 0x20 --> 0b 0100 000r (where the RW bit is shifted in from right to left)

To avoid confusion I personally like the binary expression for the I2C address, like: "0b 0101 010r"

Klaus
 

There are always 9 clock cycles in I2C frame, 9th cycle is reading ACK, failing in this case due to address mismatch.
 

    KlausST

    Points: 2
    Helpful Answer Positive Rating
There are always 9 clock cycles in I2C frame, 9th cycle is reading ACK, failing in this case due to address mismatch.
My bad. I totally forgot about the ACK.

So the ACK = HIGH, means the slave did not acknowledge.

Thanks for clarifying.
 
Last edited:

Hi everyone,

thank you very much for your answers.
Indeed it was a misunderstanding of TWAR bit positions.
Now it's working well.

Thanks a lot
Ben
 

Solution
Status
Not open for further replies.

Similar threads

Cookies are required to use this site. You must accept them to continue using the site. Learn more…