Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

[matthew...@daf.qld.gov.au]

Hello BBB Gurus,

Summary, having loaded up the device tree overlay, correctly (?) and identifying that the overlay is indeed loaded, the pin configured, and the circuit correct (all according to

http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/ ), my BBB will not detect any of the DS18B20's that I connect (I've tried 5).

I've tried a second BBB, with the same result.

I'm after suggestions to troubleshoot this further --as I have basically run aground at this point!

Some detail:

kernel:

3.8.13-bone70

Device tree overlay:

/*

* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/

*

* This program is free software; you can redistribute it and/or modify

* it under the terms of the GNU General Public License version 2 as

* published by the Free Software Foundation.

*

* Modified  by Russell Senior from the weather cape's DTS file.

* Minor formatting by C W Rose.

*/

/dts-v1/;

/plugin/;

/ {

    compatible = "ti,beaglebone", "ti,beaglebone-black";

    part-number = "BB-W1";

    version = "00A0";

    exclusive-use = "P8.11";

    fragment@0 {

        target = <&am33xx_pinmux>;

        __overlay__ {

             bb_w1_pins: pinmux_bb_w1_pins {

                 pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;

             };

        };

    };

    fragment@1 {

        target = <&ocp>;

        __overlay__ {

            onewire@0 {

                compatible      = "w1-gpio";

                status          = "okay";

                pinctrl-names   = "default";

                pinctrl-0       = <&bb_w1_pins>;

                gpios = <&gpio1 2 0>;

            };

        };

    };

};

Relevant output from dmesg:  

[    8.697062] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'

[    8.697138] bone-capemgr bone_capemgr.9: slot #7: generic override

[    8.697155] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 7

[    8.697171] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,w1'

[    8.697259] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'w1-00A0.dtbo

[    8.697274] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'w1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[    8.727950] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo' loaded; converting to live tree

[    8.728198] bone-capemgr bone_capemgr.9: slot #7: #2 overlays

[    8.757662] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.

Slots:

root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots

 0: 54:PF--- 

 1: 55:PF--- 

 2: 56:PF--- 

 3: 57:PF--- 

 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G

 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

 7: ff:P-O-L Override Board Name,00A0,Override Manuf,w1

It's not seeing any of the sensors:

root@beaglebone:~# ls /sys/bus/w1/devices/w1_bus_master1

driver  power  subsystem  uevent  w1_master_add  w1_master_attempts  w1_master_max_slave_count  w1_master_name  w1_master_pointer  w1_master_pullup  w1_master_remove  w1_master_search  w1_master_slave_count  w1_master_slaves  w1_master_timeout

Voltages across the DQ and ground pin of the DS18B20's is just under 3.3 V, and a bit higher across the power to grnd pin.

So pullup appears correct.

Could someone suggest some further troubleshooting approaches?

Hey, I'll take solutions as well!

Thanks for your help.

Kind regards

Matt

 

[Peter Lawler]

On Tuesday, 5 April 2016 08:04:14 UTC+10, matthew...@daf.qld.gov.au wrote:

Hello BBB Gurus,

Hi there, I offer no help really... but.... 

heh funny you raise this as I'm trying to get this sensor to 'work' under 4.1.18 by first trying to follow the 3.8 way of doing things then learning how the new way of things is done then intending to forward port.

Maybe there's someone out there with a 'simple' guide to porting DTO's and the like (I'm up to the stage of trying to read the "w1_slave" figure but that just doesn't exist in 4.1.18 so yeah lots more reading for me to go...). Just figured I'd add a 'me too idk what's going on' so I can keep a more easy track of this thread :)

Cheers,

Pete.

[William Hermans]

Starters for troubleshooting. After issuing the commands this person suggest on that site . . .

cp w1-00A0.dtbo /lib/firmware

echo w1 > /sys/devices/bone_capemgr.9/slots

You should run dmesg | grep w1 to see what the output is. Passed that, are you sure you have the one wire driver loaded ? I've never actually used one wire on Linux personally, but there is a generic one-wire kernel module that I've read about . . .

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[matthew...@daf.qld.gov.au]

Hi William,

Please see my original post and you will see the outputs from each of these commands.

The driver appears to be loaded perfectly. 

[William Hermans]

Hi William,

Please see my original post and you will see the outputs from each of these commands.

The driver appears to be loaded perfectly.

Seems I missed that part. Ok, so the device tree seems to load but where is the output of lsmod ? It should look something like( more or less ) with hopefully the generic one-wire module also loaded.

william@beaglebone:~$ lsmod
Module                  Size  Used by
bnep                   13297  2
rfcomm                 52320  0
bluetooth             394459  10 bnep,rfcomm
nfsd                  220016  2
sg                     24111  0
uas                    11682  0
usb_storage            47695  1 uas
evdev                   7956  0
tda998x                11683  1
tilcdc                 27869  0
omap_rng                4346  0
omap_aes               13033  0
rng_core                7233  1 omap_rng
omap_sham              19152  0
drm_kms_helper        106705  3 tda998x,tilcdc
uio_pdrv_genirq         3313  0
leds_gpio               3102  0
uio                     8350  1 uio_pdrv_genirq

[Peter Lawler]

On 2016/04/05 9:49 AM, William Hermans wrote:
> Ok, so the device tree seems to load but where is
> the output of lsmod ? It should look something like( more or less ) with
> hopefully the generic one-wire module also loaded.

My understanding was that 3.8 and above kernels needed no module, simply
the DTO. It was pre 3.8 kernels that required the kernel module. Or am I
missing something there? Certainly, every page I'm reading referring to
3.8 kernel 1Wire has absolutely no reference to kernel modules.

P.

[William Hermans]

william@beaglebone:~$ sudo modprobe w1-gpio

william@beaglebone:~$ lsmod
Module                  Size  Used by

w1_gpio                 3069  0
wire                   27112  1 w1_gpio
. . .

My understanding was that 3.8 and above kernels needed no module, simply the DTO. It was pre 3.8 kernels that required the kernel module. Or am I missing something there? Certainly, every page I'm reading referring to 3.8 kernel 1Wire has absolutely no reference to kernel modules.

So, perhaps, but if there is something wrong with the device tree blob file, the driver wont auto load. Which would give us an indication as to what's wrong.

[Peter Lawler]

On 2016/04/05 10:08 AM, William Hermans wrote:
> So, perhaps, but if there is something wrong with the device tree blob
> file, the driver wont auto load. Which would give us an indication as to
> what's wrong.
>

ahhh... *grabs another coffee*

[William Hermans]

Another thing I was noticing after greping the config, at least for my kernel version. Is that there is no Dallas One Wire kernel module for that specific device. So it could be that it is compiled in statically. I've been in menu config several times, and have noticed a lot of Dallas One Wire drivers, but could not say if that one exists in the kernel, or not . . .

[matthew...@daf.qld.gov.au]

Hi William and Peter...

root@beaglebone:~# lsmod
Module                  Size  Used by
arc4                    1691  2
zd1211rw               43946  0

mac80211              424813  1 zd1211rw
cfg80211              354018  2 mac80211,zd1211rw
rfkill                 16672  2 cfg80211
g_multi                50407  2
libcomposite           15028  1 g_multi
omap_rng                4062  0
mt7601Usta            639170  0

Using the modprobe w1-gpio produces no output.

Is this where the problem is?

Thanks

Matt

[Peter Lawler]

On 2016/04/05 10:14 AM, matthew...@daf.qld.gov.au wrote:
> Hi William and Peter...
> <snip>

>
> Using the modprobe w1-gpio produces no output.
>

'modprobe -v w1-gpio' would produce more detail (to test, use modprobe
-r w1-gpio to unload the module first).

However I'm just reading up and what William refers to seems to be if
the DTO loads properly it SHOULD load up the module, thus the module not
loading is a symptom of the DTO not being correct.

I'm currently looking at some other stuff that's indicating that maybe
my wiring isn't the best.

[REDDING Matthew]

Hi William and Peter again…

Can it actually be a module problem if it is creating the directories for the devices one wire bus, just not detecting the devices?

 

Thanks!

 

Matt

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nT93pfbvCzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

------------------------------

The information in this email together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. There is no waiver of any confidentiality/privilege by your inadvertent receipt of this material.

Any form of review, disclosure, modification, distribution and/or publication of this email message is prohibited, unless as a necessary part of Departmental business.

If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.

------------------------------

[William Hermans]

Using the modprobe w1-gpio produces no output.

Is this where the problem is?

Thanks

Matt

So, I'm not 100% sure what the problem is. I've never used One wire in linux - ever - And I'm not 100% sure what driver needs to be loaded, if any for this specific device. I'm just trying my best to help you troubleshoot the problem, because obviously there is something wrong, if the device does not show up on several boards, using several devices.

So Matt, I noticed you've changed the GPIO pin here:

gpios = <&gpio1 2 0>;



But not here:


pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;



So do keep in mind that I'm no device tree file expert. So I'm not sure if that is bad, or not. But it *seems* wrong to me. Maybe I'm wrong ?


[REDDING Matthew]

OK, I don't think this is a module I've got control over:

root@beaglebone:~# modprobe -r w1-gpio
FATAL: Module w1_gpio is builtin.
root@beaglebone:~# modprobe -v w1-gpio
<<no output>>

-----Original Message-----
From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Peter Lawler
Sent: Tuesday, 5 April 2016 10:19 AM
To: beagl...@googlegroups.com
Subject: Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nT93pfbvCzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

Guys, or just use v4.1.x, i have a nice example using P9.12:

https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

gpios = <&gpio1 2 0>



&gpio1 I'm pretty sure is reference to the gpio bank. There is 4 I think for all gpio's on the processor. The two numbers that follow . . . I honestly have no idea either.



I can hoever tell you that:


pinctrl-single,pins =  <0x34 0x37 /* gpmc_ad13.gpio1_13, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE7 - w1-gpio */ >;



0x34 is the pin number, and 0x37 is the pin mode. Which peripheral, or GPIO mode, whether it's input, or output, and whether pull up, or pull down is enabled. Pretty much my understanding here is a 32bit field with each bit indicating *something*.


On Mon, Apr 4, 2016 at 5:25 PM, REDDING Matthew <Matthew...@daf.qld.gov.au> wrote:

Eagle eyes!

 

I’ll try changing that back and see what happens.

I must confess, I don’t even know what gpios = <&gpio1 2 0>; does.

So I’m not sure where any changes came from.

 

I think I know what the other line you indicated does.

 

 

Kind regards

 

 

Matt Redding, Ph.D.

Soil Chemist/Geochemist

AgriScience Queensland

Queensland DAFF

 

0408 787100

07 46 88 1372

 

 

 

From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of William Hermans
Sent: Tuesday, 5 April 2016 10:22 AM
To: beagl...@googlegroups.com
Subject: Re: [beagleboard] Re: Troubleshooting one-wire DS18B20 detection on BBB, debian, kernel: 3.8.13-bone70

 

Using the modprobe w1-gpio produces no output.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nT93pfbvCzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

------------------------------

The information in this email together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. There is no waiver of any confidentiality/privilege by your inadvertent receipt of this material.

Any form of review, disclosure, modification, distribution and/or publication of this email message is prohibited, unless as a necessary part of Departmental business.

If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.

------------------------------

--

[Peter Lawler]

On 2016/04/05 10:27 AM, Robert Nelson wrote:
> Guys, or just use v4.1.x, i have a nice example using P9.12:
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh
>
>

I'm so embarrassed right now. I now remember thinking on Sunday 'I think
RCN shipped a demo' but never actually chased the thought up...

Will check it out immediately as I am on 4.1.x

THanks!

[William Hermans]

No idea if kernel 4.1.x will work for the OP or not.

[Peter Lawler]

On 2016/04/05 10:27 AM, Robert Nelson wrote:

> Guys, or just use v4.1.x, i have a nice example using P9.12:
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/examples/BB-W1-P9.12/example.sh
>
> Regards,
>

Followup:
After moving my data pin from 17 using my attempt at DTO to pin 12 with
RCN's *and using his example script), my DS18B20 is reading to within
0.2 degrees of my known working SHT10 sensor so I'm pretty happy about now.

Thanks Robert!

P.

[Peter Lawler]

On 2016/04/05 10:35 AM, William Hermans wrote:
> No idea if kernel 4.1.x will work for the OP or not.

Indeed. I would, however, strongly suggest that if it's for work
connected to op's mail address - Queensland (Australia) Department of
Agriculture and Fisheries - they move to a 4.1 LTS kernel as it does
have much better DTO stuff in it etc (from what I've read) and will be
far more usable to them.

P.

[William Hermans]

The problem is, there are still a few things that do not work properly in kernel 4.x yet. Or at least the last I heard. It's always worked fine for me, but I'm a hobbyist experimenter . . .

[matthew...@daf.qld.gov.au]

Thanks for the tip.

I tried correcting that line first to:

gpios = <&gpio1 13 0>;

and then to 

gpios = <&gpio2 13 0>;


I'm not sure which of these is correct, though I would have thought it was gpios = <&gpio1 13 0>;


But still no go.

Sounds like I need to change to 4.1.

I see that RCN's link leads to a bash script that allows
more time for detection?  Could this problem be related to 
not enough time being allowed for detection.

Would the script work under 3.8, and might it solve the problem?

Thanks

Matt

[William Hermans]

Probably not. At minimum, not without modifications. The problem I have here is that I have no one wire devices to test all this stuff I'm suggesting to you. Otherwise I'd have a fix for you already.

[TJF]

Hi Matt!

A year ago I started with those sensors and I didn't have trouble to connect them by the w1 kernel driver. But I don't remember what I did that time, because I dropped that solution. The kernel driver doesn't support broadcast messages and the sensors are triggered one after the other. I use eight sensors to control a solar system and there's more than five seconds between the first and the last measurement. Too much for my appliction.

That's why I made my own W1-PRU driver using a GPIO pin (no additional hardware). Now all sensors get triggered by a broadcast message, the measurements are at the same time and values are available in less than a second, which increases the speed of my controller loop. For development I implemented a feature that logs the state of the data line at 1 MHz. Those data may help you to understand what's going on on the bus.

Unfortunately I didn't find time to document and publish the project jet. The driver is based on libpruio (for pinmuxing). If you're interested let me know where to send that (undocumented) code (FreeBASIC & PRU-ASM).

BR

[matthew...@daf.qld.gov.au]

Hi TJF,

Now that is really interesting.  I was just thinking about using the PRU's for the job.

In the end I gave up and connected an mbed microcontroller and did the job.

However, that revealed an issue that could be the clue as to why I could not get the 1 wire to work with the BBB.

I interfaced the mbed to the BBB via uart 1. At first I wired it up fairly directly. I got nothing -- even though I could 

get the BBB usarts to talk to each other. 

An oscilloscope revevealed that while the mbed's tx was connected to the bbb's rx, the voltage never

went low enough to register the signal (pullup resister too strong?). So I put an optocoupler in line -- and it works 

perfectly.  

Now, in my ignorance, I'm wondering if I should try an optocoupler between the ds18b20 and the BBB.

What do you think? Maybe I don't need the mbed after all.

Kind regards

Matt 

[TJF]

Hi Matthew!

Am Freitag, 12. August 2016 06:15:51 UTC+2 schrieb matthew...@daf.qld.gov.au:

Hi TJF,

Now that is really interesting.  I was just thinking about using the PRU's for the job

...

What do you think? Maybe I don't need the mbed after all.

At my solar system controller Dallas sensors run without any additional hardware, 24/7. I'm sure you don't need the mbed.

Meanwhile I published the driver. Find it here: libpruw1 and docs at libpruw1 Documentation. The package contains example source code, which you can compile and use to test your sensor(s).

BR

[John Dammeyer]

I've not really had a lot of trouble getting my One Wire temperature sensor to function.  But there have been lots of stumbles and I'm still confused in a lot of places.  Let's start with what I'm running on a BBB RevB with the OS on a 16GB MicroSD card. 
uname -a for all shows:
Linux beaglebone 4.1.4-ti-r8 #1 SMP PREEMPT Thu Aug 6 21:01:16 UTC 2015 armv7l GNU/Linux

I've configured w1.dts and used dtc to create the w1-00A0.dto which is in /lib/firmware
Now here is where it starts to get complicated mostly because of the OS changes I believe.

First of all I've got my DS1822 (1 wire with +/-2C resolution with 22- code) wired through a connector onto the SparkFun prototype cape.  The EEROM on the cape is not yet programmed with anything so it's not in the list.  A
cat $SLOTS
shows:
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1
 5: P-O-L-   0 Override Board Name,00A0,Override Manuf,w1

Notice that neither the HDMI nor the eMMC show up like they do on all the various examples on the web.  I'm using the MicroSD card since the BBB has only 2GB.  I'm operating headless with Ethernet and puTTY s there's nothing on the USB nor HDMI connector.  Perhaps because nothing's using them?
This is an example from https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/21

$ cat /sys/devices/bone_capemgr.*/slots
0: 54:PF--- 
1: 55:PF--- 
2: 56:PF--- 
3: 57:PF--- 
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

And to get the One wire W1 virtual cape installed I've copied
 sudo sh -c "echo w1 > /sys/devices/platform/bone_capemgr/slots"

Again, this is where it's interesting.  After a restart this Debian Jesse image installs the
https://github.com/cdsteinkuehler/beaglebone-universal-io

cat $SLOTS
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln

To load the virtual One Wire I first have to remove the cape-universaln because it's already claimed the P8-11 pin I'm using for the DS1822.  That's pretty easy once we know the virtual cape #
 sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"


One other thing that's different from the various forum examples is the location of the slots file. 

cat /sys/devices/bone_capemgr.*/slots

The newer Debian image now adds 'platform' after devices and has trashed the .x after bone_capemgr. No more .7 or .9

And thenthe web documentation appears to get rather sparse.
1. I can't find where from the cape-universal.dtbo is loaded and which script puts it into the slots file.
2. There are several different copies of the cape-universaln.dts so which one is the correct one?
3. Is there a way to disable the pin used by the W1.dts so the SparkFun EEROM can be programmed with the information in the w1.dts file?  Without recompiling the cape-univesal.dts file with the reference to the W1 pin removed?

Here's where my system has the various .dts files.  Which one is loaded?  beaglebone- or bb.org-overlays? 

 sudo find -name cape-universal*
./sys/firmware/devicetree/base/ocp/cape-universal
./opt/source/beaglebone-universal-io/cape-universal-00A0.dts
./opt/source/beaglebone-universal-io/cape-universala-00A0.dts
./opt/source/beaglebone-universal-io/cape-universaln-00A0.dts
./opt/source/bb.org-overlays/src/arm/cape-universal-00A0.dts
./opt/source/bb.org-overlays/src/arm/cape-universaln-00A0.dts
./lib/firmware/cape-universal-00A0.dtbo
./lib/firmware/cape-universaln-00A0.dtbo


Thanks
John