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:
`
/*
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.
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 . . .
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.
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
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@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.
ahhh... *grabs another coffee*
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 . . .
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
'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.
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
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 ?
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>>
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.
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!
No idea if kernel 4.1.x will work for the OP or not.
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.
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.