CCS811 on NodeMCU v3

[petremihaivalentin]

I'm using NodeMCU v3 and CCS811's chinese copy (CJMCU).

I'm trying to run the basic program, to check if the sensor reads some data. At first I was receiving messages like this:

Starting CCS811 basic demo init: hardware version: 12 init: bootloader version: 1000 init: application version: 1100 errstat=10=--vhxmrwf--Ad-ie errstat=10=--vhxmrwf--Ad-ie errstat=10=--vhxmrwf--Ad-ie

and it kept going like this indefinitely. After I did a hard reset using the RST pin, I started receiving these messages:

and, again, it waits indefinitely and reads no data.

I've tried using Adafruit's library here, these were the results:

If it had failed to start, I would've been prompted with another message. Instead, it starts, but it fails to read data.

Also, I've checked everything with an i2c scanner and the sensor is recognized with its correct address. I've also used your library to check the i2c bus and everything works normally.

Do you have any suggestions? What does errstat= 10 mean? (I couldn't find anything on the web).

[maarten-pennings]

Hi, the fact that you get the three lines with the versions means that the nodemcu could communicate with the CCS811. So, the nodemcu is working, the i2c wiring is ok, and the CCS811 controller is working. Good news.

For error handling, the CCS811 has two 8-bit registers: ERROR_ID and STATUS. My library glues them together into a 16-bit variable errstat. So a value of hex 10 (the leading 0s are not printed) means hex 0010 or binary 0000 0000 0001 0000.

The binary representation is important because the single bits correspond to error flags (see datasheet). The library helps but using a letter for each flag, lower case meaning 0 and upper case meaning 1. A dash means the bit is unused.

That is the funny string behind 10= --vhxmrwf--Ad-ie One flag is up (one bit is 1) namely bit 4 (start counting from 0 from the right). This is the capital A. It means valid application firmware loaded. If I'm not mistaken, the f flag should also be high for Firmware is in application mode.

So that transition is missed. Line 169 in the cpp file checks that the F flag is set. I'm a bit puzzled.

In the second run, another flag is missing: data ready (the small d should be D).

Hmmm

[petremihaivalentin]

Thank you for your response! Now I understand better what is happening with these errors.

I'm thinking about using your flash example to update its firmware. Do you think it's a chance that will solve the problem?

[maarten-pennings]

To be honest, I have no hypothesis of what could be broken here. Easy problems like bad I2C communication, or broken heater, do not seem the case here. It does look a bit like the controller in the CCS811 is acting funny, and that could be a problem with the firmware. On the other hand, how could the firmware be half broken...?

On the other hand, your CCS811 board is not working right now, so maybe give firmware update a try.

[petremihaivalentin]

Hello!

So I've flashed the little guy and the update went without errors. Now I'm getting this I2C error, even though I haven't changed the connections since last time.

As you can see, I've also added a check with your I2C library and the errstat output. It looks like the firmware is now in application mode, but there's some problem on the I2C bus.

I've also checked the bus with an I2C scanner and the sensor is still available at the same correct address.

I'm so puzzled right now.

[maarten-pennings]

The value of errstat is not reliable now. As you can see, all bits as read by the CPU are high. This is not because they are high, this is because the CCS811 is not sending the real values; the SDA line just stays high (due to the -internal- pull up resistor) and this is interpreted as 1s.

But it is the same funny thing as before: at first the ccs811 is talking to the cpu. The proof is in the first 5 lines with all the version info; that is send by the ccs811 to the cpu over i2c. It is working.

It is as if there is an analogue problem: as soon as you really want to use the sensor, communication breaks. Maybe it is the high current needed by the MOX part, maybe the heat from the heater. I don't understand this.

Did you check your power supply. Is it strong enough? Is there an unexpected current rise?

Can you monitor the i2c traffic? At what moment doors it break down?

Can you keep talking to the chip as long as you don't switch on measuring? It's impressive that the whole flashing worked; that is a lot of successful i2c transactions sending over the firmware, without an error in the crc!

Good luck ...

[petremihaivalentin]

Hello,

So the power supply seems strong enough. I've been suspecting some faulty soldering since the beginning and I've re-soldered the connections and now the output looks like this:

It seems like the bit for error is up and the sensor says that the sensor resistance measurement has reached or exceeded the maximum range. I don't think this has anything to do with the pull-up resistor.

Do you have some ideas as how this can be solved? Should I start thinking about the sensor being fried, due to multiple soldering tries?

[maarten-pennings]

Indeed. This error code makes sense.

The A means the firmware has a valid app. The F means the app is running (and not the bootloader). The D means measurement data is available. So far so good. The E means there is an error.

Then the ERROR_ID register (the upper 8 bits) gives details. You have the X set. This means, I quote the datasheet "The sensor resistance measurement has reached or exceeded the maximum range". So the MoX paste, which is heated by the heater and then reacting with the gasses on the air and then changing resistance has a value that is out of range.

If this persist, I believe this means your mox material is fried ... :-(

[petremihaivalentin]

Hello,

It looks like my sensor was indeed fried. I've bought a new one and everything works like charm now.

Thank you so much for your help!

[maarten-pennings]

Pity it was fried - but happy it is working now!