1

tl;dr at the end

I was running two DS18B20+PAR temperature sensors without any problems for the last two years on an ESP-01 module running on 3.3V on GPIO 2 using a 4.7K pullup resistor.

Now, wanting to develop a new firmware I started the development with new versions of everything (Arduino IDE and libraries), but now, with the exact same hardware setup that worked flawlessly for two years, the sensor always returns 85°C (error code for reset during conversion). I suspect that somehow, I don't know how, the ESP does not leave the data pin powered anymore.

To test this, I recompiled and flashed my old firmware that was running fine for two years and lo and behold, it still returned 85°C. Trying to isolate the issue, I flashed the old binary of the firmware and it returned the correct temperatures again.

To isolate the issue further, I tried numerous versions of the OneWire (2.3 to 2.3.2) and DallasTemperature (3.7.3 to 3.7.9) libraries, but to no effect. I am still getting 85°C all the time.

I also tried to compile it using Arduino IDE and PlatformIO, but both yielded the same issue still. Trying on another ESP8266 (Wemos D1 mini and nodeMCU) did not change anything.

Slowly I am suspecting that the issue lies in the ESP8266-Arduino framework updating something or a change in the compiler, which now breaks keeping the data pin configured as output during the conversion.

Older versions of the ESP8266-Arduino framework (tried 2.2, 2.3, and up until latest) also produced the same error still.

A workaround, of course, is to use a lower value pullup resistor so that the sensors take power through that instead of the powered microcontroller pin. (One parasitic sensor requires 1K, two 470 Ohms) But this is not a solution.


Last weekend I debugged a bit deeper into the issue:

The OneWire library definitely leaves the pin as output (last macro called is DIRECT_MODE_OUTPUT()) and also the correct bit in the GPE pin mode register is set to output (1) during the conversion.
As far as I can see, the pin should be at 3.3V, but the oscilloscope definitely says the pin is dragged down too low (1.5V) during conversion. So it's only pulled up that far by the 4.7K pull-up resistor and not the GPIO pin for whatever reason...

I poked around here and there in the library but could not find the error. From what I can see, the code says that it should be working fine and my old binary says the hardware works fine too, but obviously it doesn't...

After five hours of unsuccessful debugging I gave up again.

I also opened an issue at the official OneWire GitHub Repo, but got no reaction in two weeks.

I will update this question in the following days by testing on other Arduino IDE versions and operating systems. Also, I want to try out the library fork from orgua to see if the issue happens in his library too.


tl;dr
- DS18B20+PAR with 4.7K pull-up always returns 85°C (error code indicating too little power on the data line) with newly compiled firmwares
- Hardware setup is working fine with old .bin
- Old code and new code freshly compiled yields error
- Doesn't depend on the library versions or what sketch is used
- Lower value pull-up resistor works, but is a dirty workaround

Hopefully someone else is able to reproduce or has already experienced this issue and is not satisfied with the workaround of using a lower pull-up resistor?

  • What pin are you using? – Craig May 8 '18 at 14:48
  • I am using GPIO2. (But it's still weird, that the unmodified hardware setup works with the old binary but not the new) – LeoDJ May 8 '18 at 19:22
  • The datasheet specifies a "strong pullup" specifically mentioning using a MOSFET for the strong pullup. Still it doesn't answer the question of why the old libraries worked. – Craig May 8 '18 at 19:37
  • Do you know what versions were used to build the old binary? Can you guess based on the lastest libraries as of the build date? – Craig May 8 '18 at 19:38
  • The datasheet probably assumes an old microcontroller with no output drivers, that can't supply even a mA. The ESP8266 however has an output driver of up to 12mA, so that should be no problem. At least in theory, as the old code worked flawlessly. – LeoDJ May 8 '18 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.