I2C read and write without stop condition

[VThan.2]

Using the HAL I2C library, is there any way to generate a continuous stream of scl and sda without a stop bit after the chip address acknowledge and data acknowledge. Otherwise I am planning to use a i2C bitbang library any recommendations? The target chip that I am using does not like the marked segment below

[Nikita91]

This is not a stop condition. The data line is allowed to change when the clock is low.

[VThan.2]

Thank you. I tried to monitor the target chip's dev board. The read and write to the chip looks like this in the below image. Seems like the data line going high is resetting the state machine on the target chip.

[VThan.2]

[Bob S]

What is wrong with this image? Looks OK to me, you are getting ACKs to the data bytes (unlike your first image). Try looking at the I2C lines with a scope. You may likely see noise, slow rise times or signal levels that are not what you (or your device) expect.

[VThan.2]

Hello Bob, Thank you for your reply. The first one image is the communication between STM32 and target chip. The second image is the dev board where the target chip communicates to its master which is an FPGA emulating I2C. When I am using the Hal write command, I get an ack for the chip ID and please ignore the noise that is me oversampling on the logic analyzer. Then I try to write the register address which is a 16 bit value, 8 bit at a time. It returns a nack for the first byte. The only difference between the dev board write and my STM32 write is after the chip ID is sent then the SDA lines float. I am thinking the data line floating back is resetting the target chip's state machine and seeing the next 0x00 I am sending as a address. Correct me if I am wrong. In that case, I think I will need a shift register based i2c to write the entire data. Sorry if this is confusing.

[TDK]

The circled blip in SDA is from when the slave releases control of SDA and the master takes it over, just after the ACK byte. It's not a violation of the standard and should not cause issues with any I2C compatible device.

Taking an analog capture will show a better picture of what's happening.

[VThan.2]

TDK thanks a ton. That is my understanding too. Here is the analog capture

[VThan.2]

Should I try to increase the resistor value for pull up. Not sure if that will help. This is operating at 1.1V. But it seems the target IC is able to discharge ack for invalid addresses. The ACK for the chip ID is at around 400mV.

[Harvey White]

You may be misled by what the analog traces are showing. Not sure what the bandwidth of your analog system is, but the pulses and transitions seem rather slow to me.

Since you mention an FPGA, that gives you some good debugging capability. I once had a problem on I2C where I was decoding (passively) the I2C data stream. The simulation worked perfectly, and the actual hardware failed. Turns out that the input stage to the FPGA was interpreting the data badly, and putting small glitches on the input, this did mess up the state machine. I put a digital low pass filter in the lines, and that fixed the problem.

So the question is not so much "what does the FPGA get" as it's "what does the FPGA think it's getting. If the input is that slow, then you'll need schmitt trigger inputs to help minimize the created noise.

IF you have a spare pin on the FPGA, run a version of the hardware that takes the signal inputs to the state machine and runs them to external pins that you can monitor. It can be a good idea to include those pins in a design if at all possible.

Decreasing the resistor value would give you a faster rise time, that might help.

If you are using an inexpensive MPU based logic analyzer, be aware that the analog channels are quite limited in bandwidth.