Unpowered device breaks bus...

[codmpm]

First, thank you for this superb library 👍

Currently we are building a soil-moisture sensor which will be released as open-source. It emulates the DS2438 and reads the temperature from an attached (real) DS18B20 as well as "borrowing" the serial number from it to get a unique device id. We ware also using the DS2438's memory to store configuration data. Additionally we work on a configuration device based on an ESP8266 to configure the sensors with a smartphone over onewire.

We are currently in the prototype phase and everything works out great. But, we are stuck with one problem:

When we cut the 5V line of the sensor (slave) the bus breaks down, meaning we can't read data anymore. We are testing with our ESP8266 implementation and an 3,3 to 5V level shifter based on a BS170. The sensor (slave) uses pin A0 of the ATMega328p and is directly wired to the onewire bus.

My first thought was the internal resistence of the ATmega when it's unpowered (A0-GND), but this should be high enough to not interfere with the pull-up for the onewire line of the master (2k2@5V).

Do you have any suggestion how to separate the onewire slave - meaning ATMega328p - when it's not powered? Did we miss something on the slave connecting to the bus?

Would be great to have your input on this.

Cheers, Patrik

[pklarsjo]

Interesting project! Remember reading somewhere that emulated devices can't use databus for supply as the original devices can, it simply consumes too much power.

[codmpm]

Hey @pklarsjo,

we do not power the MCU over the 1-wire bus itself, there's always a dedicated 5V line for this. The Problem seems, that the ATMega tries to power itself over the data line if either GND or VCC is missing.

We sepearate the MCU from the 1-wire bus by using a MAX9940 now. This will not bring down the bus if GND or VCC on the MCU are missing. Now we have only some rare circumstances where it will happen in generel.

Neverthelesse we think it's a good idea to seperate the bus from the MCU and protect the inputs with the 9940 and give it some protection.

[orgua]

what you observed is normal behaviour for MCUs. Every digital pin can source or drain a certain amount of current. The 328p is between 20 to 25mA per Pin, enough to power itself. While "booting" / coming out of reset-state the Pin-State is probably undefined, so it can pull down or up. It is also possible to be in high-impedance-mode. You should try to work with the analogue-pins! And depending on your Pull-up a simple series resistor in front of the MCU-Dataline-Input could be enough to stop it from getting to much current. The MAX9940 is total overkill for that.

[gahujipo]

@codmpm have you been able to resolve your issue?

[codmpm]

As I did not get another suggestion we went with the MAX9940. We tried @orgua's idea with the resistor in series but that does not prevent the break down of the dataline. Maybe I understood something wrong?

I'm open to any other idea.

[taliesin]

Probably this is way too late, but maybe others with the same issue find this helpful.

I use a BSS159 (and a ESD-Diode to GND directly on the connector, which is not in the schematic) to protect my 1-wire slave pins (left is bus input, right is micro controller pin).

This will prevent overvoltage on the micro controller (I'm using STM32F070 with 5V tolerant pins here) and will make the pin high impedance (above about 2V) if the micro controller power (+3.3V) is off. 3.3V is generated from +5V bus power using a linear voltage regulator with some ceramic capacitors on the output (a few 100nF).

Extremely slow ramping inputs might slowly charge the 3.3V, but with the standard 1-wire setup this usually works. You could even use a micro controller pin on the gate which is pulled high if your code has started successfully to further improve fail safe.