DS18B20 communication

Hi, there.
I’ve got an issue with DS18B20 communication.
My setup:
@beaglebone:~$ uname -r
DS18B20 connection:
VCC - BBB (pin P9.3 DC_3.3V);
GND - BBB (pin 9.1 GND);
DQ - BBB (pin 9.12);
What i did:
I modified file /boot/uEnv.txt:
###Master Enable

###Additional custom capes

After BBB reboot, the following directories are empty:
@beaglebone:~$ ls -l /sys/bus/w1/devices/
total 0
@beaglebone:~$ ls -l /sys/class/hwmon/
total 0
Also, i run:
sudo modprobe wire
sudo modprobe w1-gpio
but anyway aforementioned directories are empty (DS18B20 not detected).
What I did wrong?

Your image is very old. I would go with a current image and dtb files that are packaged with it.

yep, the image is old, i took BB-W1-P9.12-00A0.dtbo from /lib/firmware, so i didn’t compile it from dts.
The .dtbo file was already located in /lib/firmware.
I thought, it is naturally to get .dtbo from the image that i’m using.

1 Like

Oh we had issues with OneWire on some kernels.

What does, this script report:

sudo /opt/scripts/tools/version.sh


it says:

Yeap that’s old, it didn’t even find the bootloader… Can you share the serial boot log? thru J1 i want to see what u-boot is up too…


bone-log.txt (26.1 KB)

oh yuck!!!

U-Boot SPL 2017.05-rc2 (May 02 2017 - 08:53:40)
Trying to boot from MMC1
** First descriptor is NOT a primary desc on 1:1 **
*** Warning - bad CRC, using default environment

reading u-boot.img
reading u-boot.img

U-Boot 2017.05-rc2 (May 02 2017 - 08:53:40 +0530)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
** First descriptor is NOT a primary desc on 1:1 **
*** Warning - bad CRC, using default environment

<ethaddr> not set. Validating first E-fuse MAC
Net:   cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading boot.scr
** Unable to read file boot.scr **
reading uEnv.txt
355 bytes read in 4 ms (85.9 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
Running uenvcmd ...
Booting from microSD ...
reading uImage
9847360 bytes read in 620 ms (15.1 MiB/s)
reading am335x-boneblack.dtb
56827 bytes read in 11 ms (4.9 MiB/s)
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-4.14.108+
   Created:      2023-12-26  22:17:13 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    9847296 Bytes = 9.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Kernel Image ... OK
   Loading Device Tree to 8ffef000, end 8ffffdfa ... OK

Starting kernel ...

2017 that is old! pre u-boot overlays…

I don’t want to touch it, i’ll probably break your current booting…

Personally, if i was forced into it, i’d go down the direction of using the ‘device-tree-compiler’ command line utility’s to recompile and update the am335x-boneblack.dtb with the onewire node… yuck…

looking at my page here: Beagleboard:BeagleBoneBlack Debian - eLinux.org 2019.04 builds of u-boot around 2020 would be the minimal version for u-boot overlays

Here that old version of u-boot for Debian 9: https://repos.rcn-ee.net/debian/pool/main/b/bb-u-boot-am335x-evm/bb-u-boot-am335x-evm_2019.04.20211026.1-0~stretch+20220102_armhf.deb

wget https://repos.rcn-ee.net/debian/pool/main/b/bb-u-boot-am335x-evm/bb-u-boot-am335x-evm_2019.04.20211026.1-0~stretch+20220102_armhf.deb
sudo dpkg -i bb-u-boot-am335x-evm_2019.04.20211026.1-0~stretch+20220102_armhf.deb

Then you’ll find MLO/u-boot.img under: /opt/u-boot/bb-u-boot-am335x-evm/ Not sure if the install script will work on your image…

BeagleBoard.org Debian Image 2019-08-03

it would be interesting to see what fdisk shows on the partition layout: (8192 is key for newer versions)

debian@26-am335x-bbg:~$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb5001fb9

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *     8192 62333918 62325727 29.7G 83 Linux
debian@26-am335x-bbg:~$ sudo fdisk -l /dev/mmcblk1
Disk /dev/mmcblk1: 3.64 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


thanks to feedback, but i’m new to embedded Linux, not sure that i get how to handle this.
Is it possible just to download recent image?

okay, we never know, so i wanted to protect your original data…

Grab either of the (am335x) flashers from: Debian 11.x ( Debian 11.x (Bullseye) - Monthly Snapshot - 2023-10-07 ) or Debian 12.x ( Debian 12.x (Bookworm) - Monthly Snapshot - 2023-10-07 ) to make sure you wipe out the old verison on the eMMC…

For most new users, the minimal or iot is fine, just note very little is installed on the minimal image… (the xfce is really not useful on the am335x).


I thought my BBB boot from micro SD card, not from eMMC, or i’m wrong?

Default boot order is:

  1. eMMC
  2. microSD

So if u-boot on the eMMC is old, it’ll still try to boot files off the microSD but fail.

The ‘usr’ button moves up the microSD up earlier


once i update image to one of these Debian 11.x or Debian 12.x how DS18B20 should be connected (i mean which pin)? Should i make some actions to activate usage of DS18B20 or not?

I’d use P9.12, as there is a pre-built overlay already installed: src/arm/overlays/BB-W1-P9.12-00A0.dts · v5.10.x-ti-unified · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab

So in /boot/uEnv.txt just use:



currently, on my micro SD there are 2 partitions: BOOT and ROOTFS, if i download image am335x-debian-11.8-iot-armhf-2023-10-07-4gb.img.xz, do i need both of these partitions or i can make only one partition and write image to SD?

Use Balena Etcher to write the image to the microSD… https://etcher.balena.io/


after updating BBB image DS18B20 works fine, thanks for support.
My understanding of device tree overlay was correct.
What was my initial mistake? Using outdated image?

Yeah, just an old image.

gotcha, thanks a bunch for support.

Still have some questions:

  1. How to understand that certain image doesn’t support some functionality? release notes?
  2. How come that an old image that i used doesn’t support 1-wire? 1-wire is just an gpio manipulation. This looks like basic functionality.
    While using an old image I loaded 1-wire related modules manually, b/c lsmod says that they are not loaded:
    I used commands:
  • sudo modprobe wire
  • sudo modprobe w1-gpio
  • sudo modprobe w1-therm
    but none of them solve my issue (ds18b20 not detected).
    After update (5.10.168-ti-r72) i run lsmod and see these modules loaded:
    What was wrong with the first approach (load modules manually)?