CX3 I2C master generates misleading pulse before stop condition

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
MaOs_1615421
Level 2
Level 2
First like received First like given

Hi

I'm currently encountering a problem with the CX3 I2C master before the stop condition. It seems that after the last ACK the master waits too long to pull down the SDA line, allowing a pulse on the SDA line right after the slave releases it. I believe that causes some troubles in my slave's state machine as it assumes that another byte is going to be transferred. Indeed, the I2C communication is always stuck after the first write transfer. Is there a way to change the master's behaviour?

I'm using following code for testing:

uint8_t buf[2] = {0x01, 0x70};

preamble.buffer[0] = SENSOR_I2C_WRITE_ADDRESS; /* Slave address: write operation */

preamble.length = 1;

preamble.ctrlMask = 0x0000;

status = CyU3PI2cTransmitBytes (&preamble, &buf, 2,0);

0 Likes
1 Solution

Hello Marc,

Thank you for the update about the problem on slave side.

Making the changes on the master side to get one more clock after the stop bit doesn't seem  feasible. I will still check it internally.

Please let me know why the device is behaving in such manner? Or why do you need one clock cycle more? so that we can find some other solution to it.

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
3 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Marc,

Can you program CX3 with any one of UsbI2CSpiMode/UsbI2CDMAMode examples of SDK to check the I2C connection.

You need to send vendor commands from the control center to read/write data (Please refer to readme.txt file in the example folder)

While doing that can you probe the I2C lines.

Please share the waveform traces.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi

I looked a bit more into our slave and I realized that the problem is on our side. Our slave requires an additional SCL clock cycle after the stop condition to get into the idle state. However, the CX3 master immediately stops the SCL clock after the stop condition and restarts only after the start condition. This is why, our slave lacks behind one clock cycle and hence doesn't acknowledge the next write transfer. I understand that this is an issue on our side but since it is a little tricky to change the behaviour of our slave I was wondering whether we could configure the master somehow that it keeps the SCL clock running for at least another cycle after the stop condition?

Thanks

0 Likes

Hello Marc,

Thank you for the update about the problem on slave side.

Making the changes on the master side to get one more clock after the stop bit doesn't seem  feasible. I will still check it internally.

Please let me know why the device is behaving in such manner? Or why do you need one clock cycle more? so that we can find some other solution to it.

Regards,

Rashi

Regards,
Rashi
0 Likes