I2C HTU21D sensor on GY-21 not working (solved)

General
#1

If you are asking a question, please follow this template:

Hi all, my goal is to build an humidity and temperature sensor using esp8266 with I2C sensor.

  • bought some GY-21 boards with HTU21D on board

  • connected to a NodeMCUv2 just to make a first test (SDA to pin D6 - GPIO12 and SCL to pin D5 - GPIO14)

  • cloned an empty project

  • configured mos.yaml

  • built

  • flashed.

Now, from MOS tool, using “mos call I2C.Scan” nothing is found:
$ mos call i2c.scan
[
]

I tried to add anothe i2c chip on the same bus (a PCF8574AP) and, the same command returns its address as expected:
$ mos call i2c.scan
[
56
]

Also, to be sure it is not a sensor problem, I tried a couple of things:

  • on the same board I downloaded a bin created through ESPHOME, and all is working so, the sensor is found and correctly read

  • always on the same board, downloaded ESPEasy and configured the sensor … all is working fine

So, it seems to be something related to i2c … signaling ?
Have anyone had the chance to do smething like that, or have any idea ?

This is my MOS.yml

image
image.png599×606 12.9 KB

#2

Did you check the bus with an oscilloscope ?
There is no magic in i2c, you either are within specs and it always works or you are off specs and it sometimes works, or worse, sometimes does not work.
I suggest you determine the correct i2c address beforehand and directly poll that address and watch what happens with an oscilloscope. Make sure your bus voltage is OK for both chips (CPU and sensor) and have the correct pull-up resistor for that voltage (and bus frequency). Start with the lowest possible frequency (100KHz, iirc)

#3

Nothing magic, I agree with you,
I’m new to mongoose os, but not to i2c and MCUs.

I checked the bus with an oscilloscope and a logic analyzer … all signals are ok.
Also, as I mentioned, I now have on the same bus the HTU21D and a PCF8574. The second one is discovered, while the HTU21D no.
Again, in the same hw configuration, other ESP softwares work as expected.

Any other idea ?

#4

Well, I feel too lazy to check datasheets for voltages, and if I understand correctly you are using exactly the same hw with two different “OS”, so assuming voltages and pull-up values are OK, I would do exactly the same on both environments and look for differences with the oscilloscope or the logic analyzer (since we somehow ruled out voltage issues), but I would use the scope anyway until there is some dialog with the device.
Again, try coding something specific as reading an id, like (may have errors):

enum mgos_app_init_result mgos_app_init(void) {
  struct mgos_i2c *i2c = mgos_i2c_get_global();
  uint8_t somewhere[yournumberofbytestoread];
  if (!i2c) {
    LOG(LL_ERROR, ("I2C bus missing, set i2c.enable=true in mos.yml"));
    return false;
  }

  if (!mgos_i2c_read_reg_n(i2c, yourdevicei2caddr, yourdeviceregaddress, yournumberofbytestoread,
                           somewhere)) {
    LOG(LL_ERROR, ("Can't read"));
    return false;
  }
  LOG(LL_INFO, ("Got first byte as: %0x"), somewhere[0]);
  return true;
}

Invoking mos to do that involves several resets and I’d rather keep things under control.
Disable i2c.debug, just in case, you can re-enable it later…
The i2c API is here

#5

Tried to send i2c commands from code with the same result … as soon as the address with write flag is sent to the device, it answers with a NAK.

But … looking at the i2c library mos.yml, I saw the i2c1 bus configured to GPIO 5 and 4 (SCL and SDA). So, I moved the bus 0 to the same pins and suddenly i2c.scan started to find the device. So, I added the HTU21D Drivers library to my mos.yml and added the code to read temperature and humidity and now all is “magically” working.

So, now the question is … why it did not work on GPIO 14/12 while it works on 5/4 ?
I suppose there is something on signaling or bus line capacity preventing that device to work, but that’s really hard to say. I don’t think I have much time to spend to investigate this issue more.

In any case, thank you so much for your help @scaprile

#6

Well, I don’t know your hardware, probably something else is on those pins and is reacting; including some other ESP8266 peripheral.