Enable 1-wire on Jetson Xavier

I want to connect a DS18B20 sensor to a Nvidia Jetson Xavier and read its temperature. The resources below include direction for the following:

  1. jetson-gpio can configure the [GPIO pinout(NVIDIA Jetson Xavier NX GPIO Header Pinout - JetsonHacks)

  2. Kernal modification is required to enable CONFIG_W1_SLAVE_THERM and CONFIG_W1, then the driver will get enabled.

Related Posts:

Question

  1. What pin requires configuration so that the DS18B20 sensor can be read, and how can one do that with jetson-gpio to set up that pin?
  2. This post shows kernal modification, and an entry for dt as follows:
onewire@0 {
compatible = “w1-gpio”;
gpios = <&gpio TEGRA_GPIO(H, 4) 0>;
};

How to modify the kernal? Can someone give an explicit example of the commands required with a vim or terminal command?

  1. Given that instructions are provided, how can one test that the set up is correct?

As always, I appreciate your thoughtful replies. I will follow the responses to create a script/README with step-by-step instructions for the Jetson Xavier. Thanks in advance.

hello superelectron,

you should download BSP package via Jetson Linux | NVIDIA Developer for the public release sources.
there’s kernel_src.tbz2 to include kernel and device tree sources. please also check Building the NVIDIA Kernel session for the steps to build the NVIDIA kernel.
check Flashing a Specific Partition to flash a specific partition instead of flashing the whole device by using the command line option ‑k.

Thanks for the reply @JerryChang.
I have included a validation test using the raspberry pi because it is much easier to get set up. I would like to get this set up on the nvidia jetson xavier.

NOTE

I have also included more details on Q1, Q2, and Q3 from my original post below so we can follow the questions I’ve asked and see if those are indeed the path to success…




VALIDATION TEST WITH RASPBERRY PI

  • Here I am validating that the wiring set of the sensor works for UART

  • 1-wire requires UART pints to be enabled, and this is the suggested wiring from the DS18B20 datasheet on page 10.

1-wire-uart-DS18B20_maxim-datasheet
From these instructions, here is the set up I have successfully tested the DS18B20 sensor using a raspberry pi 3 B v1.2 :

1.1 Wiring
ds18b20_rpi

1.2 System Set up of 1-wire and dt


$ sudo raspi-config
# Interfacing Options ==> 1-wire ==> enable

$ echo "dtoverlay=w1-gpio" >> /boot/config.txt
sudo reboot

1.3 System config and health check

# Configure w1-gpio and w1-therm
$ sudo modprobe w1-gpio
$ sudo modprobe w1-therm

$ cd /sys/bus/w1_bus_master1
$ export SENSOR="$(find . -name 'w1_slave')"
$ echo $SENSOR
# /sys/bus/w1_bus_master1/28xxxxxx/w1_slave
$ cat $SENSOR
25 01 55 00 7f ff 0c 0c 08 : crc=08 YES
25 01 55 00 7f ff 0c 0c 08 t=18312

  • I can see YES at the end of the first line which means the rpi wiring and config is set up successfully

1.4 Code

import os
import glob
import time

os.system('modprobe w1-gpio')
os.system('modprobe w1-therm')

base_dir = '/sys/bus/w1/devices/'
device_folder = glob.glob(base_dir + '28*')[0]
device_file = device_folder + '/w1_slave'


def read_temp_raw():
    f = open(device_file, 'r')
    lines = f.readlines()
    f.close()
    return lines


def read_temp():
    lines = read_temp_raw()
    while lines[0].strip()[-3:] != 'YES':
        time.sleep(0.2)
        lines = read_temp_raw()
    equals_pos = lines[1].find('t=')
    if equals_pos != -1:
        temp_string = lines[1][equals_pos + 2:]
        temp_c = float(temp_string) / 1000.0
        temp_f = temp_c * 9.0 / 5.0 + 32.0
        return temp_c, temp_f


if __name__ == "__main__":

    try:
        while True:
            print(read_temp())
            time.sleep(1)
    except Exception as err:
        print(f"ERROR: {err}")
        print("Exiting script")
        exit()

Now I just need to do the same with the Jetson Xavier …

wiring
(left) Nvidia Jetson Xavier
(right) DS18B20 sensor

  • wiring notes
Vcc = 3v3,
Gnd = Gnd
Tx wired to Rx.
4.7 k resistor from Vcc to data



PROGRESS ON QUESTIONS

Q1. What pin requires configuration so that the DS18B20 sensor can be read, and how can one do that with jetson-gpio to set up that pin?

  • Is it suggested that I need to modify the kernal and then afterwards I can use this repo?

Q2. I have looked at the resources @JerryChang:
Jetson Linux | NVIDIA Developer
Building the NVIDIA Kernel.

  • Can you direct me to a specific part of the documentation that explicitly describes how to set up UART, or reference to CONFIG_W1, CONFIG_W1_SLAVE_THERM, and dt? I searched the docs for these keywords and have not had any success … did I miss something?

  • Is modifying the kernal how I am supposed to set up UART?

  • Am I required to flash a Specific Partition with the -k to set up UART?

Q3 If I successfully set up UART, how can I validate it?

  • on the raspberry pi I do this:
sudo cat /sys/bus/w1_bus_master1/28xxxxxx/w1_slave
  • so on the jetson would I do this?
sudo cat /dev/ttyTHS0

I am only answering a tiny subset of your questions. Be sure the “group” of “/dev/ttyTHS0” is “dialout”, and not “tty”. Note that “/dev/ttyS0” is the exact same hardware as “/dev/ttyTHS0”, and that the different device special files are only because there is both a legacy driver and a Tegra High Speed (with DMA) driver (you wouldn’t use both at the same time). If either the ttyTHS0 or ttyS0 have group tty, then it means serial console is running on that port. Here is an example:

# ls -l /dev/ttyTHS* /dev/ttyS*
crw--w---- 1 root tty       4, 64 Oct 22 13:51 /dev/ttyS0
crw-rw---- 1 root dialout   4, 65 Oct 22 13:51 /dev/ttyS1
crw-rw---- 1 root dialout   4, 66 Oct 22 13:51 /dev/ttyS2
crw-rw---- 1 root dialout   4, 67 Oct 22 13:51 /dev/ttyS3
crw-rw---- 1 root dialout 238,  1 Oct 22 13:51 /dev/ttyTHS1
crw-rw---- 1 root dialout 238,  2 Oct 22 13:51 /dev/ttyTHS2
crw-rw---- 1 root dialout 238,  3 Oct 22 13:51 /dev/ttyTHS3

Notice in the above example that ttyS0 and ttyTHS0 is the same UART, and that because ttyS0 shows a group of “tty” instead of “dialout”, the implication is that you cannot use either ttyS0 or ttyTHS0 unless you disable serial console. In many cases, if one of the other UARTs are accessible, it would be preferred to use the different UART rather than disabling serial console (especially if you are developing).

A typical temporary disable of serial console (but only after booting…this would leave boot content still using the console, which is why disabling serial console is a bit more difficult than changing UARTs) would be “sudo systemctl stop nvgetty.service”. Actually disabling this across boots would be “sudo systemctl disable nvgetty.service”, but remember that this only takes effect when Linux runs (there would still be serial console in bootloader stages, and disabling serial console in those stages is more invasive).

A typical way to test a serial console is to loopback wire its TX to its own RX. Then you could echo to the device in one place, and cat from the device in another place and the echo should appear on the cat. Or you could run a serial console program (such as minicom or gtkterm) and whatever you type in should echo back.

Do note that on non-loopback both ends need to be 3.3V logic level for the UART, and both need the same settings. The default setting is 115200 8N1. Loopback is nice because one device always agrees with itself for voltage level and port settings (unless something truly bizarre is going on).

Also, you might want to avoid flashing if you are just changing a kernel. The kernel from the “/boot” takes priority over the kernel in the partition if the extlinux.conf names the kernel. There are probably some advantages to also flashing the kernel to a partition on the Jetson models which use U-Boot (such as the TX2 dev kit), but it isn’t mandatory. If I were to flash the content to the partition I would also use file copy into “/boot” and make sure both use the same kernel so that no matter whether it is extlinux.conf or defaults picking a kernel they’d be the same.

Setting up a UART never requires flash on Jetson. Kernel changes go beyond setting up a UART, and this involves driver changes, so changing the driver probably does warrant better terminology than just “settings”. However, if the driver is not truly being changed, but only the arguments passed to the driver are changed, then the implication is that the device tree would instead need editing, and this does not require changing the kernel or drivers. A device tree is essentially a set of arguments passed to a driver for non-plug-n-play devices.

You can always ask more.

1 Like

hello superelectron,

you need to enable the kernel configs, CONFIG_W1_SLAVE_THERM and CONFIG_W1.
and please also adding below into your device tree sources to recompile the kernel image and device tree blob.

onewire@0 {
compatible = “w1-gpio”;
gpios = <&gpio TEGRA_GPIO(H, 4) 0>;
};

please check the developer guide for the steps to compile the kernel and also the flash.sh usage to update the binaries.

This is a first time go at this for me so plz be patient as I am working through this :)

Update on Q2
Here is what I get onboard the jetson xavier nx

nvidia@nvidia:/boot$ head -n 1 /etc/nv_tegra_release
# R32 (release), REVISION: 5.2, GCID: 27767740, BOARD: t186ref, EABI: aarch64, DATE: Fri Jul  9 16:05:07 UTC 2021
  • I downloaded the BSP package for public_source from here as you suggested in your first comment onto my laptop (and then I can flask over ip to the jetson or download this on the jetson?):
    https://developer.nvidia.com/embedded/l4t/r32_release_v6.1/sources/t186/public_sources.tbz2

  • I had a look inside kernal_src.tbz2 and am not sure how to include kernal and device tree sources as you mentioned above.

  • where and how I enable the kernal configs CONFIG_W1_SLAVE_THERM and CONFIG_W1

  • what file do I add/modify to include the following to my device tree?

onewire@0 {
compatible = “w1-gpio”;
gpios = <&gpio TEGRA_GPIO(H, 4) 0>;
};

thanks in advance.

hello superelectron,

you should extract this public_sources.tbz2 on your host machine, (i.e. x86 flashing machine)
please also install Jetson Linux Toolchain, then you should able to cross-compiling the release sources.
after that, you may enable scp to copy the binary file to your target for testing.

for example,
please check the makefile, /kernel/kernel-4.9/drivers/w1/slaves/Makefile
you should enable the kernel config to build this *.o to your kernel image.
obj-$(CONFIG_W1_SLAVE_THERM) += w1_therm.o
there’s /kernel/kernel-4.9/arch/arm64/configs/tegra_defconfig to define all configs.
the ways is adding CONFIG_W1_SLAVE_THERM=y into kernel config.

as you can see through flash messages,
it’s tegra186-quill-p3310-1000-a00-00-base.dtb for your Jetson TX2’s device tree blob.

[  86.1603 ] Writing partition kernel-dtb with tegra186-quill-p3310-1000-a00-00-base_sigheader.dtb.encrypt
[  86.1701 ] [................................................] 100%

please search public sources and you’ll find the sources file, /hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts.
please include the changes to enable the node property for driver usage.

1 Like

Quick UART check

  • short pins 8 and 10
  • this causes loopback (infinite) and you’ll see ‘hi’ in the other terminal (and it may crash after a few times)

Check service

nvidia@nvidia:~$ sudo systemctl status nvgetty.service
● nvgetty.service - UART on ttyTHS0
   Loaded: loaded (/etc/systemd/system/nvgetty.service; disabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2021-10-25 14:40:14 PDT; 17min ago
...

nvidia@nvidia:~$ sudo systemctl enable nvgetty.service
nvidia@nvidia:~$ sudo systemctl start nvgetty.service
nvidia@nvidia:~$ sudo systemctl status nvgetty.service
● nvgetty.service - UART on ttyTHS0
   Loaded: loaded (/etc/systemd/system/nvgetty.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-10-25 14:58:47 PDT; 5s ago
 Main PID: 15054 (nvgetty.sh)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/nvgetty.service
           ├─15054 /bin/bash /etc/systemd/nvgetty.sh
           └─15082 /sbin/getty -L 115200 ttyTHS0

Oct 25 14:58:47 nvidia systemd[1]: Started UART on ttyTHS0.

nvidia@nvidia:~$ ls -al /dev/ttyTHS* /dev/ttyS*
crw-rw---- 1 root dialout   4, 64 Oct 24 19:17 /dev/ttyS0
crw-rw---- 1 root dialout   4, 65 Oct 24 19:17 /dev/ttyS1
crw-rw---- 1 root dialout   4, 66 Oct 24 19:17 /dev/ttyS2
crw-rw---- 1 root dialout   4, 67 Oct 24 19:17 /dev/ttyS3
crw--w---- 1 root tty     238,  0 Oct 25 14:47 /dev/ttyTHS0
crw-rw---- 1 root dialout 238,  1 Oct 24 19:17 /dev/ttyTHS1
crw-rw---- 1 root dialout 238,  4 Oct 24 19:17 /dev/ttyTHS4
  • this looks good!

Test that service is running properly

terminal 1

sudo cat /dev/ttyTHS0

terminal 2

sudo echo “hi” | sudo tee /dev/ttyTHS0

  • and I saw ‘hi’ in terminal 1, so this is good!

I’ll try your suggestions here this afternoon once I get onto the proper x86 flashing machine. This is great @JerryChang

If a terminal is running on that UART (and apparently it is), then you cannot use this UART other than for serial console. Shorting pins 8 and 10 would cause errors and failure is expected for this case. You would have to disable nvgetty.service, not enable it prior to using those pins. Don’t test until this is disabled.

Once disabled you should see group “tty” disappear from “/dev/ttyTHS0” (and although it already shows no tty group for “/dev/ttyS0” you’d want to verify that both of these files no longer have group tty).

Just a detail to be aware of: Commands to echo to and read from the UART device special file will still work even when the serial console nvgetty.service is running. The problem is that whatever you send to this device also sends your content to the terminal, and of course if there is an error in the case of any command which isn’t really a command.

I do recommend using a different UART rather than disabling serial console. For example, on the TX2 dev kit the P17 connector uses a different UART, and unless you’ve installed a camera which uses that (and most cameras don’t use that, including the one coming with the dev kit) UART, then it is useful even without disabling anything.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.