I am writing a driver for an old Lego NXT ultrasonic sensor. It uses I2C, which is fine in itself, but the sensor has a well-known bug such that it does not always follow standard I2C protocol. Specifically, it requires an extra clock cycle at a certain point in the communication.This is widely known, and if you examine the various solutions people have adopted, eg on Arduino, you will see what I mean. I am using a third-party board for this purpose that provides the necessary circuitry supporting the sensor, and I can communicate with the sensor successfully, except for the specific case in which this extra pulse is required.This third-party board is designed to be an extension for an Arduino, but I am using it with an STM32F4 Discovery board. It also has an H-bridge for the NXT motors, etc, and all works well.
The third-party board has a digital I/O line physically tied directly to the SCL line so that the Arduino software can add the clock cycle when required. Without the STM32 I2C driver running I can drive that digital line to add what would be the extra clock cycle, and have verified it with a logic analyzer. However, when the I2C device is applied, I cannot affect the SCL via this backdoor I/O line. I tried disabling the I2C unit, driving the digital line for the pulse, and then re-enabling the unit, but without any observable effect.
Hence my first question: should this be possible with an I2C unit on the STM32F4 Disco board?