You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Board: esp32 pico kit
Core Installation/update date: esp32 version 1.0.0
IDE name: Arduino IDE
Flash Frequency: 40Mhz
Upload Speed: 115200
Description:
Having learned that it is now possible to install ESP32 from Arduino's Board Manager, the old ESP32 installation was removed and I've got the new ESP32 core updated to version 1.0.0. A slave device (HDMI encoder CH7035B) with slave address 0x76 has been working OK in previous ESP32 core. I2C read/write was working OK too. After ESP32 version 1.0.0 installed, I2C write working but I2C read from this slave device always return 0x00, although it has been confirmed by a logic analyzer that the slave is returning the right data.
This is the trace when I2C read from the register 0x7F.
This trace shows perfect I2C response. The slave is returning 0x14 which I have wrote to it previously.
But Wire.read() always return 0. Also tried to look into rxBuffer[] and find it is all 0 too. That means although the I2C bus is working OK "electronically", rxBuffer[] is not recording any value returned. The code snippet I am using to read a single byte is shown here:
Code:
uint8_t CH703X::hal_readRegister(uint8_t index)
{
_i2c->beginTransmission(CH703X_SLAVE_ADDR);
_i2c->write(index);
_i2c->endTransmission(false); ///STOP condition is not sent after the base address
_i2c->requestFrom(CH703X_SLAVE_ADDR, 1);
while(_i2c->available()<1)
;
uint8_t val = _i2c->read();
return val;
}
Debug Messages:
Serial output is shown below showing that I2C read from 0x76 slave device is returning 0x00 after a value 0x14 has been written to the same address at 0x7F.
On the contrary, a twist to make I2C work with the latest core is to end transmission intentionally like this:
Hardware:
Board: esp32 pico kit
Core Installation/update date: esp32 version 1.0.0
IDE name: Arduino IDE
Flash Frequency: 40Mhz
Upload Speed: 115200
Description:
Having learned that it is now possible to install ESP32 from Arduino's Board Manager, the old ESP32 installation was removed and I've got the new ESP32 core updated to version 1.0.0. A slave device (HDMI encoder CH7035B) with slave address 0x76 has been working OK in previous ESP32 core. I2C read/write was working OK too. After ESP32 version 1.0.0 installed, I2C write working but I2C read from this slave device always return 0x00, although it has been confirmed by a logic analyzer that the slave is returning the right data.

This is the trace when I2C read from the register 0x7F.
This trace shows perfect I2C response. The slave is returning 0x14 which I have wrote to it previously.
But Wire.read() always return 0. Also tried to look into rxBuffer[] and find it is all 0 too. That means although the I2C bus is working OK "electronically", rxBuffer[] is not recording any value returned. The code snippet I am using to read a single byte is shown here:
Code:
uint8_t CH703X::hal_readRegister(uint8_t index)
{
_i2c->beginTransmission(CH703X_SLAVE_ADDR);
_i2c->write(index);
_i2c->endTransmission(false); ///STOP condition is not sent after the base address
_i2c->requestFrom(CH703X_SLAVE_ADDR, 1);
}
Debug Messages:
Serial output is shown below showing that I2C read from 0x76 slave device is returning 0x00 after a value 0x14 has been written to the same address at 0x7F.

On the contrary, a twist to make I2C work with the latest core is to end transmission intentionally like this:
Code:
uint8_t CH703X::hal_readRegister(uint8_t index)
{
_i2c->beginTransmission(CH703X_SLAVE_ADDR);
_i2c->write(index);
_i2c->endTransmission(true); ///an intentional transmission STOP inserted
_i2c->requestFrom(CH703X_SLAVE_ADDR, 1);
}
Surprisingly the slave is still returning 0x14 with a STOP.

Debug Messages:
Serial Monitor is now showing the correct value too!

From books the STOP should not be there but it works somehow. Why?
The text was updated successfully, but these errors were encountered: