1-Wire in Parasite Power configuration (1-Wire using 2 wires) does not work in 3.18.3

[iz8mbw]

With the new Kernel 3.18 (3.18.3) and DT enabled the 1-Wire in Parasite Power configuration (1-Wire using 2 wires) does not work.
I'm running the latest firmware "Linux raspberrypi 3.18.3+ #742 PREEMPT Mon Jan 26 18:27:18 GMT 2015 armv6l GNU/Linux", I have this line "dtoverlay=w1-gpio-pullup,gpiopin=4,pullup=1" into "/boot/config.txt"

This is a part of dmesg:

[ 5.786145] Driver for 1-wire Dallas network protocol.
[ 5.956224] w1-gpio onewire@0: gpio pin 4, gpio pullup pin 1
[ 6.064319] w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling
[ 6.227631] w1_master_driver w1_bus_master1: Family 3b for 3b.00000014fe14.17 is not registered.
[ 6.375840] bcm2708_i2c_init_pinmode(1,2)
[ 6.382237] bcm2708_i2c_init_pinmode(1,3)
[ 6.653904] bcm2708_i2c 20804000.i2c: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100000)

The Temperature read is always 85 degrees:

root@raspberrypi:/sys/devices/w1_bus_master1/3b-00000014fe14# cat w1_slave
50 05 ff ff f0 ff ff ff 5c : crc=5c YES
50 05 ff ff f0 ff ff ff 5c t=85000

The "/etc/modules" is this:

snd-bcm2835
w1-gpio pullup=1
w1-therm
i2c-bcm2708
i2c-dev

If I try to remove both "w1-gpio pullup=1" and "w1-therm" from "/etc/modules" it's impossible to read temperature because the file "w1_slave" is not available in the directory (no such file or directory).
I have also tried to add only "w1-therm" or only "w1-gpio pullup=1" from "/etc/modules" but the results is the same:

root@raspberrypi:/sys/devices/w1_bus_master1/3b-00000014fe14# cat w1_slave
50 05 ff ff f0 ff ff ff 5c : crc=5c YES
50 05 ff ff f0 ff ff ff 5c t=85000

Instead if I disable the DT (add "device_tree=" and I remove "dtoverlay=w1-gpio-pullup,gpiopin=4,pullup=1" into "/boot/config.txt") I can correctly read temperature.

[pelwell]

Can you show me the equivalent dmesg entries for when DT is disabled?

[iz8mbw]

DT disabled:

[ 13.601207] Driver for 1-wire Dallas network protocol.
[ 13.623344] w1-gpio w1-gpio: gpio pin 4, gpio pullup pin 1
[ 13.635920] w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling
[ 13.735257] w1_master_driver w1_bus_master1: Family 3b for 3b.00000014fe14.17 is not registered.

[iz8mbw]

Hi.
Just for info, also with the Kernel "Linux raspberrypi 3.18.4+ #743 PREEMPT Wed Jan 28 17:14:53 GMT 2015 armv6l GNU/Linux" the problem is the same.
Also by assigning the pullup on the Pin 5 (so not more Pin 1 as before) "dtoverlay=w1-gpio-pullup,gpiopin=4,pullup=5" into "/boot/config.txt" the problem is the same.

[pelwell]

I'm at a bit of a loss. @mati75 had a similar problem here but he fixed that with the dtoverlay.

Sadly I'm not a Onewire expert, and I'm busy on other things at the moment. I do have a DS18B20 module working, but that doesn't need the pullup feature.

[iz8mbw]

I'm NOT using DS18B20 but a Maxim MAX31826 (http://datasheets.maximintegrated.com/en/ds/MAX31826.pdf) this a little more precise then DS18B20.
But anyway the 1-Wire protocol is the same and with DT disabled it works well in Parasite Power configuration.
But for what I read, he solved with "device_tree_overlay=overlays/w1-gpio-pullup-overlay.dtb" so it should be 1-Wire NOT in Parasite Power configuration ("normal" 1-Wire using 3 wires).
May be that dtoverlay works well for a "normal" 1-Wire (using 3 wires) but not for 1-Wire in Parasite-Power Mode (using 2 wires).

I have tried with "device_tree_overlay=overlays/w1-gpio-pullup-overlay.dtb" instead of "dtoverlay=w1-gpio-pullup,gpiopin=4,pullup=1" but the problem is still here...
The only different from "device_tree_overlay=overlays/w1-gpio-pullup-overlay.dtb" and "dtoverlay=w1-gpio-pullup,gpiopin=4,pullup=1" seem that the first one assign by default the Pin 4 to GPIO and Pin 5 to Pullout, with the second one you can specify the Pins.

[pelwell]

If you can point me at a description of the parasite power mode of operation (it's my first exposure to it) I would find it very helpful.

[iz8mbw]

1-Wire protocol use by default 3 wires: 1. Vcc (the power supply), 2. Data (GPIO #4), 3. GND (Ground).
1-wire in Parasite Power mode will go to use only 2 wires: the GND and the Data (GPIO #4), the power supply for the chip will be "stolen" from the Data Pin (in Parasite Power mode the Vcc Pin of the chip will be connect to GND).

Before 3.18 Kernel in Raspberry Pi, the 1-Wire can be used using 3 wires (normal) or using 2 wires (Parasite Power configuration).
So, using 1-Wire in Parasite Power mode with the Raspberry Pi, we are going only to use GPIO #4 (Raspberry Pi Name GPIO 7) and GND.
A 4.7 kohm pull-up resistor between the 3V3 (GPIO #1) and the GPIO #4 is always needed.

The oldest Raspberry Pi Kernel did not support Parasite Power mode, but there was a patch that enabling it (see here: raspberrypi/linux#186).
The 1-Wire in Parasite Power mode was available from the rpi-update firmware as of 8 March 2013.

So, now, any chance to have again the 1-wire in Parasite Power mode support also for 3.18 Kernel?

[pelwell]

Thanks for the pointers. This will get fixed, but perhaps not today.

[iz8mbw]

Ok, thanks! I'm available for test it!

[pelwell]

It looks as though the patches that add the Parasite Power mode, as well as being confusing, don't provide any way to enable the Parasitic Power mode from DT.

However, I think there is a workaround that uses a combination of DT and module parameters:

• Enable DT

• Add dtoverlay=w1-gpio (not the -pullup variant, although it shouldn't matter)

• Add w1-gpio to /etc/modprobe.d/raspi-blacklist.conf

• Add to/keep in /etc/modules:

  w1-gpio pullup=1
  w1-therm

• Reboot

Here's what's happening:

• DT creates the platform device node, including the GPIO pin number, but doesn't load the driver because it's blacklisted.
• When /etc/modules is processed the driver is loaded (the blacklist is irrelevant now), finds both the DT node and the module parameter, and hopefully has the desired effect.

My DS18B20 seems happy with or without the fancy footwork required for parasitic power, but I hope your MAX31826 will appreciate the difference.

If this workaround is successful then it will prove that I've understood the issue, and a fix should be relatively easy.

[iz8mbw]

Hi.
I have:

1. Enable DT (remove "device_tree=")
2. Add "dtoverlay=w1-gpio"
3. Add "blacklist w1-gpio" to /etc/modprobe.d/raspi-blacklist.conf
4. Keep in /etc/modules:

w1-gpio pullup=1
w1-therm
5.Reboot

The results is quite different but the problem is not solved, now the sensor answer always this:

root@raspberrypi:/sys/devices/w1_bus_master1/3b-00000014fe14# cat w1_slave
00 00 00 00 00 00 00 00 00 : crc=00 NO
50 05 ff ff f0 ff ff ff 5c t=0

And the output of the command "cat w1_slave" has become very very slow.

This is lsmod:

Module                  Size  Used by
tun                    20798  2
xt_nat                  1930  1
iptable_nat             2176  1
nf_conntrack_ipv4      14554  1
nf_defrag_ipv4          1739  1 nf_conntrack_ipv4
nf_nat_ipv4             6214  1 iptable_nat
nf_nat                 17191  2 nf_nat_ipv4,xt_nat
nf_conntrack           96746  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
ip_tables              12393  1 iptable_nat
x_tables               18646  2 ip_tables,xt_nat
i2c_dev                 6709  0
w1_therm                3325  0
w1_gpio                 4068  0
wire                   31280  2 w1_gpio,w1_therm
cn                      5756  1 wire
snd_bcm2835            21342  0
snd_pcm                93100  1 snd_bcm2835
snd_seq                61097  0
snd_seq_device          7209  1 snd_seq
snd_timer              23007  2 snd_pcm,snd_seq
snd                    67211  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
ftdi_sio               31878  0
usbserial              30821  1 ftdi_sio
i2c_bcm2708             6004  0
uio_pdrv_genirq         3666  0
uio                     9897  1 uio_pdrv_genirq

The /etc/modules:

snd-bcm2835
w1-gpio pullup=1
w1-therm
i2c-bcm2708
i2c-dev

The /etc/modprobe.d/raspi-blacklist.conf:

blacklist spi-bcm2708
#blacklist i2c-bcm2708
blacklist dvb_usb_rtl28xxu
blacklist snd_soc_pcm512x
blacklist snd_soc_bcm2708_i2s
blacklist w1-gpio

The last lines of /boot/config.txt:

dtparam=i2c1=on
dtoverlay=w1-gpio

[pelwell]

Hi. Having untangled the options in the w1-gpio driver, in the end the problem wasn't in that driver at all. One of the major differences between running with and without DT is that the two modes use different GPIO drivers. The DT GPIO driver (the less-used pinctrl-bcm2835 driver) was missing a vital part of the gpio_direction_output method; it was correctly setting the direction but ignoring the initial level, which resulted in the w1 device never receiving any power.

Along with that fix, and the sanitised w1-gpio parameter handling, there are new overlays; these expose the new parameter ("extpullup", to specify an external pullup enable pin), and route "pullup" to the new "rpi,parasitic-power" DT property. The updates will appear in the /boot/overlays/README file, but you can get a preview here: http://www.raspberrypi.org/forums/viewtopic.php?p=684151#p684151

Thanks for your patience and help - it's been a learning experience.

[iz8mbw]

Hi.
Ok, many thanks! I hope this fix will be released soon in the next rpi-update.
So, now, in my case that I use "1-Wire in Parasitic Power configuration (1-Wire using 2 wires)" how should I set the overlays in /boot/config.txt?
Is so correct: "dtoverlay=w1-gpio,pullup=1" ?

[pelwell]

Yes, just like that, if you want to use GPIO 4 (pin 7) for your data line. Since "pullup" is effectively a boolean, you can use also some other values - "on", "y", "true" etc. For a different GPIO, use:

dtoverlay=w1-gpio,gpiopin=5,pullup=on

[popcornmix]

Firmware is updated.

[iz8mbw]

Hi.
Now with the DT enabled and this fix the 1-Wire in parasitic Power configuration works, thanks!!!
These are the last lines of /boot/config.txt

dtparam=i2c1=on
dtoverlay=w1-gpio,gpiopin=4,pullup=on

But please I have only two questions: I use both I2C and 1Wire, now with DT enabled.
in /etc/module I still have that lines:

snd-bcm2835
w1-gpio pullup=1
w1-therm
i2c-bcm2708
i2c-dev

Should I remove them?

More, in /etc/modprobe.d/raspi-blacklist.conf
I have these lines:

blacklist spi-bcm2708
#blacklist i2c-bcm2708
blacklist dvb_usb_rtl28xxu
blacklist snd_soc_pcm512x
blacklist snd_soc_bcm2708_i2s

So "i2c-bcm2708" is NOT blacklisted, should I blacklist again it?

Thanks!

[pelwell]

I'm happy to hear it is working now. Your config.txt looks correct, although you could, if you wanted, change the first line to:

dtparam=i2c_arm=on

which will enable the ARM side i2c whichever model of you Pi you use.

Looking at /etc/modules, you still need to load modules that don't talk directly to hardware. In your case that means you want:

snd-bcm2835
w1-therm
i2c-dev

Blacklisting modules stops them being loaded automatically, but now that we are using DT to only enable devices that we want you shouldn't need to blacklist anything (unless you want to defer loading to a later time). I suggest you comment out all of the entries, reboot, and then look for modules that you don't want.

[iz8mbw]

ok!
Thanks.

[pelwell]

Can we close this now?

[iz8mbw]

sure!

[christophfroehlich]

Has anyone tested a DS18B20 with parasite power on the RPI B+ and 3.18.7+ #755?
I added in /boot/config.txt: dtoverlay=w1-gpio,gpiopin=4,pullup=on
and in /etc/modules:

snd-bcm2835
w1-therm

but I just get random number in /sys/bus/w1/devices starting with 00-
or dmesg output

[   69.396971] w1_master_driver w1_bus_master1: Family 0 for 00.800000000000.8c is not registered.

But the sensor works!
If I disable the device tree

sudo raspi-config
Goto 8) Advanced -> A5) Device Tree and choose no.

add in /etc/modules

snd-bcm2835
w1-gpio pullup=1
w1-therm strong_pullup=1

I get the sensor with the correct ID and temperature in /sys/bus/w1/devices (28-000005f5c23e)

any suggestions? tanks a lot!

[pelwell]

When using device tree, why did you omit the strong_pullup=1 module parameter in /etc/modules? Try putting it back.

And yes, I have used a DS18B20 on a Pi2 with DT in parasitic power mode.

[pelwell]

And a B+.

[christophfroehlich]

I just applied the proposed settings from above and. I tried now with /etc/modules

snd-bcm2835
w1-therm strong_pullup=1

still no sensor found with the same dmesg-errors! I tried it also with strong_pullup=2, which didn't change anything.

[pelwell]

I think I understand your problem now. I quickly hooked up a DS18B20 and, to my surprise, it didn't work. Sure enough, disabling device tree made it work. I then realised that I had omitted the 4.7K pull-up resistor that is required on the data line (check the datasheet). Adding this got it working again with device tree.

So, why does using DT make a difference? The answer is that the overlay had set the internal pull-up state of the GPIO pin 4 to none, expecting an external pull-up resistor, but the default for that pin is high. The problem with relying on the internal pull-ups is that they are 50-60KOhms, and not guaranteed to give enough current - you might get away with it, but you might not.

The right solution is to add the 4.7K resistor between the 3.3V line and the data pin, but if that is too much effort and you would rather continue to chance it then you can get an unofficial, use-at-your-own-risk overlay here.

[christophfroehlich]

Thank you! with your version of the overlay it works without a problem.
I didn't think about the pull-up resistor, because it worked without before ;)

[RobThree]

Doesn't seem to work 😢

whips out soldering iron

[pelwell]

Thanks for contributing, @iz8mbw.

The new way to load the audio driver is dtparam=audio=on. On a 4.4 kernel, putting snd-bcm2835 in /etc/modules doesn't work. You can also empty or delete raspi-blacklist.conf. The other entries look OK though.

[RobThree]

I've resoldered ("reflowed") all connections, tried the 5V pin instead of the 3.3V pin, tried pin 9 instead of 6 for GND (read that somewhere), again tried different combinations of settings but nothing works.

The one thing I didn't try is a single sensor. But, honestly, it was just a proof-of-concept project for fun and I've spent way to much time on it as-is. I'm done with it. Sensors will be binned, RPi1 will probably go collect dust as it did before my little project. I give up. Screw it.

To anyone else with the same/similar problem: good luck; I hope it's just my RPi or (one of the) sensor(s) being broken and not something software related / stupid config thingy everybody overlooks. I'm pretty sure I broke it somewhere down the line with some apt update or rpi-update or whatever; I just can't recall when. All I know is my RRD graphs stop at about last friday, around 23.30 2016-06-23 22:08:04 UTC. And I'm 100% sure I didn't do anything to the RPi then (since it was my father-in-laws birthday which I attended straight out of work from 19.30 to about 03.30...).

So below are the last graphs ever from my RPi / sensors. It was fun while it lasted. Too bad.

[pelwell]

I'm sorry we couldn't solve this one for you, but from the software perspective everything seems correct.

One thing about using a Raspberry Pi is that there is a huge community of users, many of whom are happy to offer help and advice, especially on our forums. I would encourage you next time to try asking there before your frustration level gets too high.

[RobThree]

I'm sorry we couldn't solve this one for you

Don't feel bad. All it cost me is < €10 in hardware (sensors) and the RPi didn't have a purpose before either and time (initially only an hour or two of fun/exploring to get it up and running, reading instructions etc. and writing my own 'sensor-over-http' script; today however I've spent > 4 hours fiddling and it's just not worth it). You, and others, have been very helpful and I've read a lot of forumposts and blogs and whatnots before finally giving up. If this were a serious project I'd have spent some more time on it (maybe I will someday) but for now it's just not worth my time and frustration (changing a minor thing, reboot, test, nothing, lather, rinse, repeat). Thank you and everyone who helped. I'm just going to spend my spare time with something less frustrating 👍 😉

If anything, I hope I contributed back a little by sharing my script.

[colinrgodsey]

I've also been facing the same issue, mine is more intermittent though. A 'hard' power cycle (few seconds between unplugging and back in) would usually bring my sensors back, but over time I'd start seeing the "00-#" devices show up, sometimes my '28' therms would be there, but usually not responsive, and eventually vanish usually.

So far I've gotten a far more stable setup (3 sensors) using:

• w1-gpio pullup=0
• w1-therm strong_pullup=2
• 4k7 physical pullup (no parasite power)

Not only is it more stable, but the responsiveness from the w1_slave sysfs entry has gone through the roof, and I no longer see software timeouts trying to read from em. I'm starting to think the 4k7 might be too weak of a pullup? Only time i see the '00-#' devices predictably is when the pullup resistor isnt there. So it almost seems like over time, it starts acting like there's not an efficient pullup, and in this case the additional strong_pullup seems to help.

I'm wondering if there's some kind of hardware support on those GPIO pins that will change the pull up/down config under surges or something. Most of the breakout 1w masters I've seen usually have some kind 'surge (echo?) protection' support, plus the DS2482 1w masters themselves seem to have far more advanced pull-up and timing support that might circumvent this entirely. Also has 'active pullup' which i think is more for parasite mode... but would probably help some of you. I think there's a really good chance the PI hardware/software just cant handle these situations as well via GPIO. Especially with the fact that I have to hard reboot the device to get w1/GPIO responsive again. It almost does seem like the hardware lost track of the pin configuration?

[colinrgodsey]

gahh!!! I immediately regret looking at any of those 'getting started' guides on these therm sensors. If we go straight to the source, there's buckets of valuable info:

https://www.maximintegrated.com/en/app-notes/index.mvp/id/148

@RobThree I noticed we both have the same config- 3.3v 1-wire in a 'star' topology. I'm guessing you're also using the therms that come prewired like mine.

So, two really good takeaways from those notes:

• Start topologies are the most unstable. The equal lengths of wire make it really easy for 'reflections'/echos to happen. (all 3 devices hook up to the master at the same distance)
• 3.3v requires a strong pull-up. The docs seem to recommend a 1k for 3.3v. (1.6k for 5v)
• Devices add 'wire length' of about 0.5m. So my 3 meter long cables and therms results in about 4.5m of 'length'.
• Multi device busses really should be linear and have a 'terminal' endpoint.

[RobThree]

Haven't had time to go through the entire source you pointed out, but my wires are (IIRC) 1.7m long, 2m at most. Also I'm quite sure it's a software problem; it has worked weeks and months before I somehow managed to break it with some update; I can't recall which. Either way thanks for your insights and input; If I ever get around to fiddling with it again I'll get back to this issue/thread.

[pstolarz]

@RobThree your issue made me interested ;) Have you resolved it already or not?

[RobThree]

Nope. It just happens that I tried yesterday again (pure coincidence) to give it one more go. Formatted the SD and started with a clean install. Whichever combination I tried of al of the above suggestions, none of them worked. The one thing I haven't tried yesterday (but tried before) is a single sensor since that would require de-soldering my current setup and I wasn't in the mood for that (which means I also didn't try with/without pull-up resistor nor which value (Ω) that would (need to) be).

[pstolarz]

Could you do the following and give me results:

1. Set dtoverlay=w1-gpio in \boot\config.txt (I'm assuming you don't use parasite powering).
2. If you have any 1-wire related stuff in /etc/modules (eg. w1-therm, w1-gpio, wire) comment it out. It's not necessary for new kernels with DT support.
3. After RPi reboot check by lsmod you have wire and w1-gpio loaded. w1-therm should NOT be present.
4. Now clone my librasp repo and compile its examples.

I'm assuming you have gcc and GNU Make installed.

git clone https://github.com/pstolarz/librasp
cd librasp/examples

In Makefile in examples dir change the line

CFLAGS=-Wall -I../inc

to

CFLAGS=-Wall -I../inc -DDEBUG

and compile (from examples dir) by:

make

Then put:

sudo ./w1_list

And give me its output. Similarly give me an output for:

sudo ./dsth_list

[pstolarz]

Your setup consists of 4 sensors with 4.7k pull-up resistor as presented on the fig before, right?

[RobThree]

Your setup consists of 4 sensors with 4.7k pull-up resistor as presented on the fig before, right?

Currently: yes.

Could you do the following and give me results:

Will try, as soon as I have the time. Don't hold your breath though, might take a while!

[kbhuinfo]

I managed to handle the issue with following config:

pi@kbhu_3:~$ uname -a
Linux kbhu_3 4.1.18+ #846 Thu Feb 25 14:11:56 GMT 2016 armv6l GNU/Linux

gpio pin 24, with 4k7 pullup resistor
2 pieces of 1 wire 18b20: first is with normal 3 wire, second is with 2 wire parasitic power

/boot/config.txt
dtoverlay=w1-gpio,gpiopin=24,pullup=on

/etc/modules
#empty

pi@kbhu_3:~$ dmesg | grep w1
[    7.728045] w1-gpio onewire@0: gpio pin 24, external pullup pin -1, parasitic power 1
[    7.828744] w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling

[TheSashmo]

Can anyone help me out? I've tried all the different type of option but I cant get a good reading from my sensors. I have 7 sensors, that I want to eventyall go to like 50, but anything more than ONE, gives me one in celsius and the other in farheniet. With more, I get random results, some celcius and some in farenehit.

root@RS232-1:~# ./test.sh
25
79.5
77
75.5
26
77.5
25.5

Linux RS232-1 4.4.27-v7+ #2 SMP Wed Oct 26 19:09:12 UTC 2016 armv7l GNU/Linux

root@RS232-1:~# dmesg | grep w1
[    5.956270] w1-gpio onewire@0: gpio pin 4, external pullup pin -1, parasitic power 1
[    5.956352] w1_add_master_device: set_pullup requires write_byte or touch_bit, disabling

My sensor is the D18B20150sc4+760AA

Any ideas?

[TheSashmo]

I think I may have solved my own problem.... 3.3v rail is not enough to do more than one sensor. Switched to the 5v, as the datasheet says it can take 5v. Booom all is working good.

I will still take any free input ;)

[yfaykya]

What do you use to protect your pi from the 5V?

[TheSashmo]

I tapped into the 5v from the power supply which is directly on the board on pin 1, IIRC

[DMike92]

Hi,
I have never tested my /etc/modules file with w1-therm but mine has always worked with w1_therm.

[pelwell]

man modprobe says:

DESCRIPTION
       modprobe intelligently adds or removes a module from the Linux kernel: note that for
       convenience, there is no difference between _ and - in module names (automatic underscore
       conversion is performed).

In other words, the two - w1-therm and w1_therm- are equivalent.

[DMike92]

Thanks for this info :-)

[msloan75]

I wish this could be resolved. I'm thinking of switching to Arduino because I'm using this rPi to run my brewery but keeping these sensors up is frustrating.

[iz8mbw]

Still using 1-Wire in parasitic power configuration without any problems.

[DMike92]

@msloan: Could you post a picture showing pins used, 3V, 5V, etc. ?

[brabl2]

Hi,
I had working setup of two 1-Wire devices (DS18B20) in parasite mode.
/boot/config.txt: dtoverlay=w1-gpio,gpiopin=4,pullup=on
It stopped working right after the kernel upgrade to the latest version
Linux raspberrypi 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
Both sensors are correctly detected by the system, however reporting 85000, which is value after sensor restart. From the symptoms, it looks that the strong pull-up necessary for the parasite mode is not working.

pi@raspberrypi ~ $ ls /sys/bus/w1/devices/
w1_bus_master1  28-000000429998  28-000002f1e200

pi@raspberrypi ~ $ cat /sys/devices/w1_bus_master1/28*/w1_slave
50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
50 05 4b 46 7f ff 0c 10 1c t=85000
50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
50 05 4b 46 7f ff 0c 10 1c t=85000

Can anybody confirm that 1-Wire devices in parasite mode are working in the latest kernel?

[tony1tf]

Thanks for this observation. I run One-wire sensors on my "Open Pi" unit which contains the original compute module. I never upgrade its firmware, as I assume that on such an old unit, it could easily be 'broken'. I hope you get a solution. Tony

…

On Wed, 22 May 2019 at 11:59, brabl2 ***@***.***> wrote: Hi, I had working setup of two 1-Wire devices (DS18B20) in parasite mode. /boot/config.txt: dtoverlay=w1-gpio,gpiopin=4,pullup=on It stopped working right after the kernel upgrade to the latest version Linux raspberrypi 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux Both sensors are correctly detected by the system, however reporting 85000, which is value after sensor restart. From the symptoms, it looks that the strong pull-up necessary for the parasite mode is not working. ***@***.*** ~ $ ls /sys/bus/w1/devices/ w1_bus_master1 28-000000429998 28-000002f1e200 ***@***.*** ~ $ cat /sys/devices/w1_bus_master1/28*/w1_slave 50 05 4b 46 7f ff 0c 10 1c : crc=1c YES 50 05 4b 46 7f ff 0c 10 1c t=85000 50 05 4b 46 7f ff 0c 10 1c : crc=1c YES 50 05 4b 46 7f ff 0c 10 1c t=85000 Can anybody confirm that 1-Wire devices in parasite mode are working in the latest kernel? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#348?email_source=notifications&email_token=ABJKGTWE4DJOZQSRNFHRVT3PWURPVA5CNFSM4A3A5LFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV6VYPI#issuecomment-494754877>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJKGTQEN6EXIWEGOCOE44DPWURPVANCNFSM4A3A5LFA> .

[JamesH65]

@brabl2 Please create a new issue for that much more recent kernel. This issue was for 3.18 and has been closed for some time.