ds18b20 with BBGW

[Sebastián Sáez]

Hi!

I'm trying to read temp with a ds18b20 sensor. I try with a few tutorial without luck.

Any tips for read this sensor?
I'm using Debian 8.6 2016-11-06 4GB SD SeeedStudio IoT (kernel 4.4.30-ti-r64)


regards,
Sebastián

[Dennis Lee Bieber]

Number 2: "We want... Information"

On Wed, 30 Nov 2016 20:03:21 -0800 (PST), Sebastián Sáez
<otr...@gmail.com> declaimed the following:

>
>I want to read temp with a ds18b20 sensor. I try with a few tutorial
>without luck.
>
What does "without luck" mean?

Program aborts with segfault?

Program runs but reports unrealistic values?

Program hangs up -- and if it does, on what statement (sample of your
code would be useful, along with some description of how you have the
sensor wired).
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[acheesehead]

I also am having no luck. I created an overlay:

root@beaglebone:~# cat w1-p9-13.dts

/dts-v1/;

/plugin/;

/ {

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

    part-number = "BB-W1";

    version = "00A0";

    /* state the resources this cape uses */

    exclusive-use =

        /* the pin header uses */

        "P9.13",

        /* the hardware IP uses */

        "gpio0_31";

    fragment@0 {

               target = <&am33xx_pinmux>;

               __overlay__ {

                    dallas_w1_pins: pinmux_dallas_w1_pins {

                        pinctrl-single,pins = < 0x74 0x37 >;

                    };

               };

    };

    fragment@1 {

               target = <&ocp>;

               __overlay__ {

               onewire@0 {

                   compatible      = "w1-gpio";

                   pinctrl-names   = "default";

                   pinctrl-0       = <&dallas_w1_pins>;

                   status          = "okay";

                   gpios = <&gpio1 31 0>;

               };

         };

    };

};

Compiled and then copied it to /lib/firmware as BB-W1-P9-13-00A0.dtbo. Did echo BB-W1-P9-13 > /sys/devices/platform/bone_capemgr/slots. 

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

 0: PF----  -1

 1: PF----  -1

 2: PF----  -1

 3: PF----  -1

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9-13

tail of dmesg shows:

[  221.082070] bone_capemgr bone_capemgr: slot #6: 'Override Board Name,00A0,Override Manuf,BB-W1-P9-13'

[  221.108759] bone_capemgr bone_capemgr: slot #6: dtbo 'BB-W1-P9-13-00A0.dtbo' loaded; overlay id #0

[  223.111781] w1_master_driver w1_bus_master1: w1_search: max_slave_count 64 reached, will continue next search.

There is no activity on the oscilloscope for that pin.

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

00-400000000000  w1_master_add              w1_master_remove

00-800000000000  w1_master_attempts         w1_master_search

driver           w1_master_max_slave_count  w1_master_slave_count

power            w1_master_name             w1_master_slaves

subsystem        w1_master_pointer          w1_master_timeout

uevent           w1_master_pullup           w1_master_timeout_us

Have tried other overlays on different pins. No luck. The sensor is good, since I checked it out on a WiPy V2.0 board.

Am frustrated by this.

Board info:

root@beaglebone:~# uname -a

Linux beaglebone 4.4.29-bone-rt-r14 #1 PREEMPT RT Tue Nov 1 21:30:09 UTC 2016 armv7l GNU/Linux

[Sebastián Sáez]

Hi Dennis,

I attach my circuit. It's connected to P9_22 with a pullup 4.7K resistor. Now I'm trying with BBGW-blank-debian-8.5-seeed-iot-armhf-2016-06-19-4gb

I try with this module from this tutorial:

/dts-v1/;
/plugin/;
 
/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";


    part-number = "BB-W1";
    version = "00A0";
 
    /* state the resources this cape uses */
    exclusive-use =
        /* the pin header uses */


        "P9.22",


        /* the hardware IP uses */


        "gpio0_2";


 
    fragment@0 {
               target = <&am33xx_pinmux>;
               __overlay__ {
                    dallas_w1_pins: pinmux_dallas_w1_pins {


                        pinctrl-single,pins = < 0x150 0x37 >;


                    };
               };
    };
 
    fragment@1 {
               target = <&ocp>;
               __overlay__ {
               onewire@0 {
                   compatible      = "w1-gpio";
                   pinctrl-names   = "default";
                   pinctrl-0       = <&dallas_w1_pins>;
                   status          = "okay";
 

                   gpios = <&gpio1 2 0>;
               };
         };
    };
};

I notice that the bone_capemgr from /sys/devices/bone_capemgr.9/slots to /sys/devices/platform/bone_capemgr/slots

I can't found the w1 kernel module at  /sys/bus/w1/devices/DEVICE_ID/w1_slave

regards,

Sebastián

[William Hermans]

You device tree file is wrong. First lets look at this compared to your file: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-W1-P9.12-00A0.dts#L25-L27

    exclusive-use =
        /* the pin header uses */
        "P9.22",
        /* the hardware IP uses */
        "gpio0_2";



should be:



    exclusive-use =
        /* the pin header uses */


        "P9.22";




The comment is also wrong, but whatever, it shouldn't hurt anything.



Second:



fragment@1 {
               target = <&ocp>;
               __overlay__ {
               onewire@0 {
                   compatible      = "w1-gpio";
                   pinctrl-names   = "default";
                   pinctrl-0       = <&dallas_w1_pins>;
                   status          = "okay";
 
                   gpios = <&gpio1 2 0>;
               };



The code in bold is wrong. The gpio bank for this pin is bank0:

gpios = <&gpio0 2 0>; would be the correct assignment.



Lastly, your overlay "compatible" assignment is wrong for your board. It should look like this:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-W1-P9.12-00A0.dts#L18


[William Hermans]

Another problem I'm seeing with your "wiring diagram". You're powering the sensor via 3v3, but you still have the parasitic power resistor in place.  It is my understanding if you're wanting to power the DS18B20 from the dataline. In whcih case the resistor would be between Vdd, and DQ pins (pins 2 and 3 ). *HOWEVER* keep in mind that I'm pretty sure you can not power the DS18B20 from the beaglebone's GPIO pins.

Anyway, I just happen to have a DS18B20 in hand at this very moment. So I'll hook up some jumper wires from the P9 headers for ground, 3v3, or 5v, and a data pin to give it a test. I'll even write, or more correctly modify the existing 1-wire dtb i linked to earlier to match your exact needs.

As it just so happens I have to get 1-wire working myself. As I'm in the process of designing my own 1-wire slave devices.

[William Hermans]

1-wire workflow:

Hardware setup:

Everything is directly connected via jumper wires, with no additional components.

DS18B20 PIN1 connected to Beaglebone P9.1  (ground)
DS18B20 PIN2 connected to Beaglebone P9.22 (1-wire data)
DS18B20 PIN3 connected to Beaglebone P9.5  (Vdd 5v)


Remove any currently loaded overlays that might be using P9_22, then reboot.

Install git if need be:
william@beaglebone:~/dev$ sudo apt-get install git

git clone the bb.org-overlays repo:
william@beaglebone:~/dev$ git clone https://github.com/beagleboard/bb.org-overlays

Move into the source directory:
william@beaglebone:~/dev$ cd ./bb.org-overlays/src/arm

Find the file we're looking for:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ ls |grep W1
BB-W1-P9.12-00A0.dts

Make a copy of the file while renaming it in one go:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ cp BB-W1-P9.12-00A0.dts BB-W1-P9.22-00A0.dts


Edit copied 1-wire overlay source to suit our needs:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ diff BB-W1-P9.12-00A0.dts BB-W1-P9.22-00A0.dts
4c4
<  * Virtual cape for onewire on connector pin P9.12
---
>  * Virtual cape for onewire on connector pin P9.22
21c21
<       part-number = "BB-W1-P9.12";
---
>       part-number = "BB-W1-P9.22";
27c27
<               "P9.12";
---
>               "P9.22";
35c35
<                                       BONE_P9_12 0x37
---
>                                       BONE_P9_22 0x37
51c51
<                               gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
---
>                               gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;

Backout to the base path:
william@beaglebone:~/dev/bb.org-overlays/src/arm$ cd ../..

Build our newly created overlay:
william@beaglebone:~/dev/bb.org-overlays$ make ./src/arm/BB-W1-P9.22-00A0.dtbo

"Install" our overlay:
william@beaglebone:~/dev/bb.org-overlays$ sudo cp ./src/arm/BB-W1-P9.22-00A0.dtbo /lib/firmware/

Load our overlay:
william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P9.22' > /sys/devices/platform/bone_capemgr/slots"

Check if the overlay loaded:
william@beaglebone:~/dev/bb.org-overlays$ cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P9.22

 william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1
[ 2826.626795] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.22', version 'N/A'
[ 2826.626871] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-W1-P9.22'
[ 2826.641278] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-W1-P9.22-00A0.dtbo' loaded; overlay id #0

Check to make sure kernel modules loaded or not:
william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
w1_therm                4886  0
w1_gpio                 3764  0
wire                   35398  2 w1_gpio,w1_therm

Check sysfs:
william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
28-00000647ddf6  w1_bus_master1

Read from our sensor:
william@beaglebone:~/dev/bb.org-overlays$ cat /sys/bus/w1/devices/28-00000647ddf6/w1_slave
16 01 4b 46 7f ff 0a 10 98 : crc=98 YES
16 01 4b 46 7f ff 0a 10 98 t=17375

Pat self on back for job well done !

[William Hermans]

I should probably note that when I connected everything up. I had the beaglebone powered down, and completely disconnected from everything.

[acheesehead]

In all of the examples that I have seen, the P9.x -> GPIO bank.port translates to GPIO (bank +1).port between lines in the overlay script.

On Wednesday, November 30, 2016 at 8:58:19 PM UTC-7, Sebastián Sáez wrote:

[William Hermans]

On Thu, Dec 1, 2016 at 10:39 PM, acheesehead <achee...@gmail.com> wrote:

In all of the examples that I have seen, the P9.x -> GPIO bank.port translates to GPIO (bank +1).port between lines in the overlay script.

That's incorrect if I understand what you're trying to say. the P8/P9 header values for the pins have absolutely no correlation to the kernel pin values. These values can be gleaned from the schematics. But I typically use something like the attached file( in pdf format ) that lists all the important data I need.

For example P9.22 has a kernel gpio value of gpio0_2. What this means is that the pin is on gpio bank0 ( bank zero ), and is pin 2 of that gpio bank. Note, that on the beaglebone there are 4 GPIO banks. gpio0-gpio3. Now with this in mind. to figure out the sysfs gpio number you would . ..

gpio_bank * 32 + pin number. So, for the sysfs file entry for the P9.22 pin. Our pin would be gpio2. But for example, and arguments sake. If this pin were on gpio_bank 1, then the sysfs entry for this pin would be gpio34. gpio_bank 1 * 32 + 2.

Irregardless, I just gave you a step by step, exact steps recipe to success. That I wrote as I figured it out for the first time myself.

[William Hermans]

Ah forgot the screenshot . . .

[William Hermans]

Note the "mode7" column to the far right.

[TJF]

@Sebastián Sáez

Perhaps you're ready to test the libpruw1 project:

• pinmuxing handled by libpruio -> single source, just choose the bus pin in your source code (no device tree magic necessary)
  
• transparent bus input and output -> broadcast triggering of multiple sensors, fast readings
• monitoring feature -> watch what's going on at the bus @ 1MHz sampling rate (find interferences, sensor failures, ...)

Find example source code at this link.

Regards

[Sebastián Sáez]

That's it !, Many thanks Williams

It works perfect

[Sebastián Sáez]

thanks TJF for the tips :)

[acheesehead]

Thanks William. I'll try out your instructions on Mon.

[Sebastián Sáez]

sorry Williams but now I have another problem with this.

My temperature sensor work fine but when I load our overlay the Mraa module stop working. I think our overlay replace this overlay "univ-bbgw"

root@beaglebone:/firmware# python test.py
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    pir = mraa.Gpio(73)
  File "/usr/lib/python2.7/dist-packages/mraa.py", line 912, in __init__
    this = _mraa.new_Gpio(pin, owner, raw)
ValueError: Invalid GPIO pin specified

test.py 

import mraa
import time
pir = mraa.Gpio(73)
pir.dir(mraa.DIR_IN)
while True:
    print (pir.read())
    time.sleep(1)

regards,

Sebastián 

[William Hermans]

On Fri, Dec 2, 2016 at 2:37 PM, acheesehead <achee...@gmail.com> wrote:

Thanks William. I'll try out your instructions on Mon.

One thing I did not mention last night was that I did all this one a beaglebone black running . . .

william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-10-30
william@beaglebone:~$ uname -r
4.4.27-ti-r62

So, someone mentioned in the last couple of days ( I think ) that they're using a 3.8.x kernel. A couple of concerns with this is that a) the overlays as described by me may not work the same. Meaning, I do not recall if 3.8.x overlays are slightly different or not. Through the source, or in how dtc compiles the source into "binaries". b) The sysfs file entries are possibly going to be different.

Honestly, I could not say for sure, because last night was the very first time I've setup 1-wire on the beaglebone. I just know / knew how to modify the overlay's source in order for it to be proper. How to wire up the sensor through a buddy of mine( someone with 35+ years electronics design experience ). Here, see everyone on the web is saying to run a 4.7k resistor between Vdd, and DQ on the sensor. Even if you're externally powering the sensor. Where I've been told this is not necessary, and that the resistor is only needed if you're going to parasitically power the sensor through the DQ pin. Which my buddy does not seem convinced that this sensor can be powered through a Beaglebone GPIO. So "erroring" on the side of caution least I burn out a GPIO pin, or worse yet the processor. I opted to power via an external power source. Also reading the datasheet I noticed the input voltage range for the sensor is something like 2v8 to 5v6 ish . . . I just powered the sensor straight off P9.5( 5v ). Indeed, in the end, it seems to work perfectly fine this way. But I did not double check the temp output to make sure it was accurate. I am however reasonably convinced it's fine. I'll double check later with another kind of temperature sensor that I know is accurate within a degree or two. Close enough for me . . . we even have some K-type thermocouplers here( MAX31855 ) that are very accurate if it ever comes to that. I haven't done SPI on the beaglebone yet though . . . Anyway . . .

The image I'm using is the one Robert says is the latest Jessie "release" image that will be shipping with the BBGW's soon( I believe ). Everything else as far as I can remember is pretty stock. Except I've installed a few Debian packages that should have no bearing on this subject at all ( build-essential, git, nfs-client. acpid, maybe i2c-tools, etc ).

Wait, one thing I did change in /boot/uEnv.txt:

##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb

I do not think this overlay is loaded by default on the stock image. For the pin I chose, I do no think it's related to hdmi at all. But if you're going ot use a different pin, you should double check to make the pin does not conflict with the hdmi pins. Or some other board function. Picking I2C0, or I2C2 pins would also not work out very good. As well as the eMMC pins, if you're running off the eMMC . . . standard double check everything.

[William Hermans]

By the way, for informational purposes. The board file I'm loading( am335x-boneblack-emmc-overlay.dtb ) for my BBB should also work with BBG's too. At least I've used it with several Greens, and have had zero problems with it. Now, when I say "several" think in the range of 40-50 different boards . . .

[William Hermans]

Sebastián,

I do not know what to say. You possibly have a pin conflict in one of your overlays somewhere. I'd check through all the source file for the dtbo's you're using, and make sure there are no P9.22 references in an of them. Except the 1-wire overlay file.

[Dennis Lee Bieber]

On Thu, 1 Dec 2016 22:28:09 -0700, William Hermans
<yyr...@gmail.com> wrote:


>DS18B20 PIN1 connected to Beaglebone P9.1 (ground)
>DS18B20 PIN2 connected to Beaglebone P9.22 (1-wire data)
>DS18B20 PIN3 connected to Beaglebone P9.5 (Vdd 5v)
>

Is that safe? I'd think the 5V would influence the swing of the data
line, and I thought the BBB is supposed to only have 3.3V on the inputs.

[William Hermans]

On Fri, Dec 2, 2016 at 8:10 PM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

        Is that safe? I'd think the 5V would influence the swing of the data
line, and I thought the BBB is supposed to only have 3.3V on the inputs.

You know, it ran over night no problems, the sensor still working fine. I was however under the impression that I/O on the DQ pin was 3v3. Then my buddy saw your post and said " You know thats probably not good, I'm pretty sure there is no I/O regulation on the data pin . . ."

So, I moved the Vdd jumper wire to P9.3 ( 3v3 ). 

So yeah just goes to show when it comes to the physical aspects of electronics . . . I'm about good enough to be dangerous ;) In the future you see me talking about the physical characteristics of electronics . . .don't take my word on it ! I'm really not an EE.

Wouldn't it be nice if I could edit my exact steps guide to reflect my mistake here ?

[Sebastián Sáez]

Again, thanks Williams... that was it.

I commented everything about P9.22 in ./bb.org-overlays/src/arm/univ-bbgw-00A0.dts

Then build and install with your instruccions :)

Which is an elegant way to mount the w1 overlay automatically after reboot?

By the way, I switched my VCC to 3.3V

regards,

Sebatián

[William Hermans]

On Sat, Dec 3, 2016 at 10:52 AM, Sebastián Sáez <otr...@gmail.com> wrote:

Again, thanks Williams... that was it.

I commented everything about P9.22 in ./bb.org-overlays/src/arm/univ-bbgw-00A0.dts

Then build and install with your instruccions :)

Which is an elegant way to mount the w1 overlay automatically after reboot?

There are a few different ways. Pretty much you can google search for "debian boot script", and find around 3 different ways, that I can think of off the top of my head.

1. write a script that's called by rc.local
2. write a startup service, there are two ways to do this.
3. create a one time at boot cron job.

In my mind, using Debian Jessie, creating a systemd service is the correct way to go about this. But in case that turns out to be too difficult, or cumbersome for your needs. Technically LSB sysv type services are also possible in Jessie. These are also rather hard to understand at first too. So writing a script, and then calling it from rc.local is probably the easiest way - Initially.

Cron jobs, in my mind are not  really the right way to go. Because again, in my mind, cron jobs are meant to run something repeatable. Meaning running something multiple times. Once a day at a specific time, Once every hour, minute, whatever you like. However, it is possible to run a cron job once every reboot. . . .

I would however recommend that you read up on systemd services, and use that method.

[William Hermans]

@ Sebastian

Ah I forgot to mention loading capes from /boot/uEnv.txt. So . . .

william@beaglebone:~$ cat /boot/uEnv.txt |grep cape
#cmdline=coherent_pool=1M quiet cape_universal=enable video=HDMI-A-1:1024x768@60e
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=
#cape_disable=bone_capemgr.disable_partno=

cape_enable=capemgr.enable_partno=<overlay_name> is the way to go. You can assign multiple cape overlays with this feature, but I do not remember if they are space, or comma separated. I'm thinking comma separated, but may be wrong.

That's the first step.

The second step would be to . . .

Copy all your required overlays into /lib/firmware, which you've probably already done.

william@beaglebone:~$ cd /opt/scripts/
william@beaglebone:/opt/scripts$ git pull
william@beaglebone:/opt/scripts$ cd tools/developers/
william@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh

What this does, is notes what's in uEnv.txt in the way of enabled capes, then which overlays you have in /lib/firmware, and "injects" these overlays into the initramfs. This is important, and if not done, your overlays will not load at boot using this method. But the upside is that once done, this will load your overlays at boot faster than any other method. Near instantly at boot, 1-2 seconds tops.

Anyway, this method is fairly easy, and is actually the best way to go.

[William Hermans]

I repeated this process for P8.14, and it works fine. This is just to let others who may not be aware that you can use 1-wire on any gpio pin that is not already in use by the system. Again, double check the pins in the schematic, to make sure they're not being used by somethign like HDMI( which you can disable hdmi audio and video if you do not need it. ), or i2c-0 / i2c-2, emmc, sdcard, etc. But again you have to of course change the overlay to reflect the pin you need to use.

william@beaglebone:~$ diff ./dev/bb.org-overlays/src/arm/BB-W1-P8.14-00A0.dts ./dev/bb.org-overlays/src/arm/BB-W1-P9.12-00A0.dts
1c1,2
< /*
---
>
>                          /*
4c5
<  * Virtual cape for onewire on connector pin P8.14
---
>  * Virtual cape for onewire on connector pin P9.12
21c22
<       part-number = "BB-W1-P8.14";
---
>       part-number = "BB-W1-P9.12";
27c28
<               "P8.14";
---
>               "P9.12";
35c36
<                                       BONE_P8_14 0x37
---
>                                       BONE_P9_12 0x37
51c52
<                               gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
---

>                               gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;

[William Hermans]

*OR* P8.26 . . . *smacks hardware designer / buddy . . .

william@beaglebone:~/dev/bb.org-overlays$ diff src/arm/BB-W1-P8.26-00A0.dts src/arm/BB-W1-P8.14-00A0.dts
4c4
<  * Virtual cape for onewire on connector pin P8.26
---
>  * Virtual cape for onewire on connector pin P8.14
21c21
<       part-number = "BB-W1-P8.26";
---
>       part-number = "BB-W1-P8.14";
27c27
<               "P8.26";
---
>               "P8.14";
35c35
<                                       BONE_P8_26 0x37
---
>                                       BONE_P8_14 0x37
51c51
<                               gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
---

>                               gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;

william@beaglebone:~$ cd dev/bb.org-overlays/
william@beaglebone:~/dev/bb.org-overlays$ make ./src/arm/BB-W1-P8.26-00A0.dtbo
  DTC     src/arm/BB-W1-P8.26-00A0.dtbo
william@beaglebone:~/dev/bb.org-overlays$ sudo cp ./src/arm/BB-W1-P8.26-00A0.dtbo /lib/firmware/

william@beaglebone:~/dev/bb.org-overlays$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

william@beaglebone:~/dev/bb.org-overlays$ sudo sh -c "echo 'BB-W1-P8.26' > /sys/devices/platform/bone_capemgr/slots"

william@beaglebone:~/dev/bb.org-overlays$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-W1-P8.26

william@beaglebone:~/dev/bb.org-overlays$ dmesg |grep W1

[  210.416201] bone_capemgr bone_capemgr: part_number 'BB-W1-P8.26', version 'N/A'
[  210.416276] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-W1-P8.26'
[  210.430251] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-W1-P8.26-00A0.dtbo' loaded; overlay id #0

william@beaglebone:~/dev/bb.org-overlays$ ls /sys/bus/w1/devices/
28-00000647ddf6  w1_bus_master1

william@beaglebone:~/dev/bb.org-overlays$ cat /sys/bus/w1/devices/28-00000647ddf6/w1_slave
19 01 4b 46 7f ff 07 10 eb : crc=eb YES
19 01 4b 46 7f ff 07 10 eb t=17562

Anyway, dead horse . . . point made?

[acheesehead]

Tried your workflow today without success. Everything is OK up to the lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel expert, so I don't know how to troubleshoot why the other entries aren't showing up.

I didn't see any activity on the oscilloscope either.

[William Hermans]

On Mon, Dec 5, 2016 at 7:30 PM, acheesehead <achee...@gmail.com> wrote:

Tried your workflow today without success. Everything is OK up to the lsmod | grep w1 step. I only get the w1_gpio entry. I am not a Linux kernel expert, so I don't know how to troubleshoot why the other entries aren't showing up.

I didn't see any activity on the oscilloscope either.

 

Then, you must be using a 3.8.x kernel. Right ? But here are the modules needed at least on a 4.x kernel:

william@beaglebone:~/dev/bb.org-overlays$ lsmod |grep w1
w1_therm                4886  0
w1_gpio                 3764  0
wire                   35398  2 w1_gpio,w1_therm

All three of those need to be loaded in order for the DS18B20 to work. So, try manually loading those via modprobe. SO let's take a look at a rPI blogpost: https://www.modmypi.com/blog/ds18b20-one-wire-digital-temperature-sensor-and-the-raspberry-pi

Much of this blog post is going to be RaspberryPI centric. dtoverlay=w1-gpio, /boot/config.txt, etc. However if you scroll down to the "Programming" part of the blog post. This person talks about loading the required kernel modules( also note that kernel version is 3.6.11 ) Using modprobe. So if you run those two modprobe commands, and then list the contents of /sys/bus/w1/devices:

william@beaglebone:~$ ls /sys/bus/w1/devices/
28-00000647ddf6  w1_bus_master1

And you get output like the above. 1-wire *is* working, and the 1-wire master ( beaglebone ) has detected a 1-wire slave device. It's working. However, if you load both the above 1-wire kernel modules, and there is nothing in /sys/bus/w1/devices, then something is wrong. I'd have to say at this point, if you do not get an error about a missing module, that you have your pin muxed incorrectly, or not properly connected to the pin.

Now if you get an error on the command line from trying to load either of those two 1-wire modules. Chances are pretty good you haven't compiled in the given proper 1-wire support. In fact, I do believe there is a whole section in menu-config for 1-wire devices. You may actually have to recompile your kernel with support for the DS18B20 1-wire device . . .

Another issues between 4.x, and 3.8.x kernels is that device enumeration was different for some devices. So . . . It is entirely possible, in your overlay, that the GPIO bank you're passing in as parameters is off by one. How can be test for this ? On 4.x kernels . . .

william@beaglebone:~$ ls /sys/devices/platform/ocp
40300000.ocmcram          48042000.timer    480ca000.spinlock              49800000.tptc      driver_override
40302000.ocmcram_nocache  48044000.timer    4819c000.i2c                   49900000.tptc      modalias
44e07000.gpio             48046000.timer    481ac000.gpio                  49a00000.tptc      ocp:l4_wkup@44c00000
44e09000.serial           48048000.timer    481ae000.gpio                  4a100000.ethernet  of_node
44e0b000.i2c              4804a000.timer    481d8000.mmc                   4c000000.emif      power
44e35000.wdt              4804c000.gpio     48200000.interrupt-controller  53100000.sham      subsystem
44e3e000.rtc              48060000.mmc      48310000.rng                   53500000.aes       uevent
47400000.usb              480c8000.mailbox  49000000.edma                  56000000.sgx

william@beaglebone:~$ ls /sys/devices/platform/ocp/44e07000.gpio/gpio/
gpiochip0

And the very first gpio address entry in this case was the lowest gpio bank. So, if you investigate the equivalent directory in 3.8.x, you should be able to check all gpio banks, to see what the actual lowest gpio bank is. Do also keep in mind that /sys/devices/platform/ocp/ will be different in 3.8.x. So you'll have to poke around a bit. Unless someone else posts here and gives you the proper path. I don't remember what it is.

Anyway, there is another option. You can upgrade your kernel to a newer version. Which, yes, will probably mean you'll also have to either flash a newer image, or run a newer image from sdcard.

[William Hermans]

Actually the last bit probably wont work because:

william@beaglebone:~$ ls /sys/devices/platform/ocp/*.gpio/gpio/
/sys/devices/platform/ocp/44e07000.gpio/gpio/:
gpiochip0

/sys/devices/platform/ocp/4804c000.gpio/gpio/:
gpiochip32

/sys/devices/platform/ocp/481ac000.gpio/gpio/:
gpiochip64

/sys/devices/platform/ocp/481ae000.gpio/gpio/:
gpiochip96

You wont get an actual gpio bank number. Just the bank offset. So going by this beaglebone blogpost: http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/

gpios = <&gpio2 13 0>;  /* P8.11*/

I show P8.11 as gpio1_13 in my pinmux pdf file. So yes, 4.x versus 3.8.x, for gpio banks are definitely off by one. Looks like for 3.8.x kernel gpio banks start at gpio1, and I know for a fact that gpio banks in 4.x start at gpio0.

Anyway, very good chance your overlay file is slightly wrong. Based on off by one gpio bank.

[William Hermans]

Nope, actually that persons overlay file is wrong. So yeah I don;t know time to learn Linux and start troubleshooting your problems ;)

[acheesehead]

Thanks William. I'll try out your suggestions when I get to the office.