cancel
Showing results for 
Search instead for 
Did you mean: 

I2C master quarter clock pulse

JW.4
Associate II

I am working with an STM32F405 and have the I2C1 peripheral set up as a master in standard mode with a clock speed of 100 kHz.  The i2c bus has about 5 devices attached to it, none of which are capable of running in master mode.  I'm using the HAL_I2C_Master_Transmit and HAL_I2C_Master_Receive functions to communicate with the devices.  99.9% of the time I'm able to communicate with these devices without any issue, but once every few thousand transactions I'm getting a timeout error from the transmit function when trying to write the device address to SDA.

When looking at one of these transactions with a scope, I'm seeing what I can only describe as a runt clock pulse when trying to perform an i2c write to address 0x71:

runt_pulse.jpg

This behavior is very confusing to me for multiple reasons.  The obvious one is SCL being clamped back to ground halfway through the fifth positive clock edge.  But the more I look at this, the weirder things get.

For one, the next positive clock edge occurs out of phase with how the clock has been behaving up to this point.  The sixth positive edge seems to be occurring when the negative edge for the fifth clock cycle would have happened, which I would think means that the i2c peripheral believes that enough APB clock ticks have occurred for it to need to assert the sixth clock cycle.

The second odd thing is that this transaction should be an attempted write to address 0x71, which means that there should be one more clock cycle's worth of SDA being driven low after it gets driven high for the last bit of the address seen in the transaction.  If the i2c peripheral did consider the runt clock pulse to be valid, then the assertion of SDA should have come one clock cycle earlier for it to be the last address bit going out on the line.  But if the i2c peripheral is not considering the runt clock pulse to be valid, then there should be one more clock pulse after the SDA was asserted (the R/Wn bit) before the ACK period, during which SDA should have been asserted low.

Are there any conditions that could explain why the I2C peripheral would go from asserting the SCL pin to deasserting the SCL pin partway through the clock edge like this yet still continue with the remainder of the transaction?

0 REPLIES 0