Unable to read from BME280

[rudi ;-)]

.. If it helps, I've ported the Arduino i2c driver to a IDF FreeRTOS C project, and get similar results.

I'm trying to write 2 bytes to a small OLED using i2cWrite(), and only see the address and first byte on the logic analyzer.

Looking at the i2c registers, all the status bits look as expected, but the last command (I2C_CMD_STOP) never completes and the i2c driver gets stuck in a loop waiting for it.

can you post / share the code on github what you have ported just in time and can we try
your code?

if not possible, can you test your "register write", "register clear" code with this add after each write, clear:

Code: Select all

void reg_delay (void) {
   
   __asm__ __volatile__("nop;nop;nop;nop;nop;nop;nop;nop;");
   
}

and how you setup your I2C pins on start?
do you "toggle shake" the gpio pins before use it?

do you setup GPIO pins as "openDrain" and set it to high in init?

thanks!
best wishes
rudi

[kolban]

In my tests, I took the following article:

https://learn.sparkfun.com/tutorials/bm ... or-hookup-

with the associated code ... which is Arduino based and ran it under the Arduino-ESP32 environment.

When I run an I2C scanner (on ESP32) the BMP180 shows up just fine. However, when I run the sketch, I don't get "values" back from the sensor. I then broke out my logic analyzer and examined the I2C traces. What I seem to see is that I2C commands which are one byte are honored just fine. However if we perform the equivalent of:

Code: Select all

Wire.beginTransaction(address);
Write.write(2 bytes of data);
Wire.endTransaction();

Then the first byte of the 2 bytes is written but then nothing more and we end up "looping" inside of "write". This story has been reported to the Arduino library author and he is presumably examining the situation. For me, I am patient to wait for an eventual consideration.

[onehorse]

I tried to read an MPU9250+MS5637 board which I can do just fine with the STM32L4 Dev Board but with my ESP32 Dev Board using pins 21 (SDA) and 22 (SCL) I can sometimes see 0x68 and 0x76 I2C addresses on the bus bot can't even read the WHO_AM_I register of the MPU9250. I'll try other pin pairs.

[shadow]

Hi,
@rudi

- which Pull up ( Value ) you use for each ( SDA, SCL )
- have you tried to swap SDA, SCL Pins
- have you tried to use other GPIO example GPIO16, GPIO17

how looks your code in the IDE, can u post the complett Sketch?

1. Seems I don't use any pull up
I've just found out about these.
Using Google I found that I could use some resistors (10k? 4k7? any guides on these and how to use those on a breadboard?), or the less desired approach, by enabling the internal pullup on the pins, but I don't know how to do that either.

Edit: reading the hookup guide again, I see it says the sensor board has pull-ups for both I2C and the SPI CS, so I understand from this that there shouldn't be any need for extra resistors (?).

2. Tried swapping the SDA and SCL pins, but it seems to be stuck in setup

3. I don't know how to do that. I'm only using a library and that seems to use the Wire lib, and that seems to use the default SDA/SCL pins, which are 21 and 22. Any idea how to change them?

The sketch I used is the one from the examples, I2C_ReadAllData.ino

Now, the good news is that I made it work in SPI mode, but using the Adafruit_BME280 library, in hardware mode.
Unfortunately, even the Adafruit_BME280 library doesn't find the sensor using I2C, but now it might be because I don't have pullup resistors.

[dldtechnology]

I got my version of the driver working now, and am using it with an I2C OLED no problem.

Issue seems to be that when the driver populates the tx FIFO, the FIFO doesn't always catch the data byte, so the value stored in the I2C_CMD_WRITE command is more than the actual values in the TX FIFO, causing the driver to get stuck waiting for more bytes.

My fix (esp32-hal-i2c.c) is:

Code: Select all

        i = 0;
        uint32_t fifotail = 0;

        while(i<dataSend) {
            i++;
            fifotail = i2c->dev->fifo_st.tx_fifo_end_addr;
            i2c->dev->fifo_data.data = data[index++];

            while(i2c->dev->fifo_st.tx_fifo_start_addr == fifotail) {};	// Wait for FIFO to update
        }
        i2cSetCmd(i2c, 1, I2C_CMD_WRITE, willSend, false, false, true);
        dataLen -= willSend;

Not sure if that will help with the Arduino case - ideally we need someone who knows the hardware a bit better to check my logic!

[shadow]

Hi,
I see an issue that might be connected to the same problem: https://github.com/espressif/arduino-esp32/issues/81

Maybe you can comment there too?

[ESP_Me-no-dev]

@dldtechnology That is an interesting find! One would think that when you write to the register, the data will latch And I did not read anything in the bus specs to give the idea that such check should be performed.
Another issue that I'm looking at is clock stretching with some slaves to timeout too early.
Need to buy a whole bunch of I2C things and look at the ones that do not work... LadyAda could be really helpful about now

[ESP_igrr]

This may be the same issue which is mentioned in the errata, about FIFOs missing data if they are addressed via the fast bus.

[rudi ;-)]

This may be the same issue which is mentioned in the errata, about FIFOs missing data if they are addressed via the fast bus.

yeap.. same thinking here.
ordered 280 now too, have only the 180 version here.
best wishes
rudi

[ESP_Me-no-dev]

Just committed this: https://github.com/espressif/arduino-es ... a27e3b6012
I hope it helps