Overlay for MAX31856

[dennyfmn]

According to PhilE there is support for the MAX31856 in kernel 5.9 but no overlay yet. Ref:
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=288967
I would like to request this to be created, I would test it if it were available. Thanks!

[pelwell]

If PhilE says so then he's probably correct. ;-)

Although I can have a guess at what a suitable overlay might look like, I would prefer to have it tested before adding it to the kernel. Are you running 5.9 at the moment, or more importantly, are you prepared to upgrade so you can test whatever I come up with?

[dennyfmn]

I have a brand new current stable 5.4.51+ #1333 system that I'm testing the MAX6675 with. I can easily clone it and update to 5.9 for testing. I would intend to use it with a type K thermocouple. I'd be very pleased to work with you.

[pelwell]

I've opened a Pull Request (#3916) with the modifications to the maxtherm overlay to support the MAX31856. You can download a build of the overlay here: https://drive.google.com/file/d/1YSHc3-WQAO4gZHKLbJ1GtHXPOL2RYDad/view?usp=sharing
Just copy it into /boot/overlays/ (you'll need to use sudo cp ...). The updated README gives usage information:

linux/arch/arm/boot/dts/overlays/README

Line 1668 in 17a22a7

Name: maxtherm

[dennyfmn]

Cool! I have an Adafruit MAX31856 board on order, it should be here on Saturday. I'll let you know how it goes...

[dennyfmn]

Ok I have it connected with this in /boot/config.txt
dtoverlay=maxtherm,spi0-0,max31856,type_k (also tried without ,type_k same results)
I have this structure at /sys/bus/spi/devices/spi0.0
-rw-r--r-- 1 root root 4096 Oct 24 17:04 driver_override
-r--r--r-- 1 root root 4096 Oct 24 17:04 modalias
lrwxrwxrwx 1 root root 0 Oct 24 17:04 of_node -> ../../../../../../../firmware/devicetree/base/soc/spi@7e204000/maxtherm@0
drwxr-xr-x 2 root root 0 Oct 24 17:04 power
drwxr-xr-x 2 root root 0 Oct 24 17:04 statistics
lrwxrwxrwx 1 root root 0 Oct 24 17:04 subsystem -> ../../../../../../../bus/spi
-rw-r--r-- 1 root root 4096 Oct 24 17:03 uevent
cd of_node | ls -l
-r--r--r-- 1 root root 15 Oct 24 17:04 compatible
-r--r--r-- 1 root root 9 Oct 24 17:04 name
-r--r--r-- 1 root root 4 Oct 24 17:04 phandle
-r--r--r-- 1 root root 4 Oct 24 17:04 reg
-r--r--r-- 1 root root 0 Oct 24 17:04 spi-cpha
-r--r--r-- 1 root root 4 Oct 24 17:04 spi-max-frequency
-r--r--r-- 1 root root 4 Oct 24 17:04 thermocouple-type

cat compatible
maxim,max31856

cat thermocouple-type
returns nothing

od -cx thermocouple-type
0000000 \0 \0 \0 003
0000 0300
0000004

I'm not sure where to look next.

Just to let you know I connected one of my MAX6675 boards with
dtoverlay=maxtherm,spi0-0,max6675 in /boot/config.txt and it works fine under kernel 5.9 and the new overlay file.
It supplies data in /sys/bus/iio/devices/iio:device0/

BTW, I also copied the new README file to the overlays directory, so the help shows the new changes.

How would you like to proceed? Is this the right venue for working on this?

[dennyfmn]

I installed a python library from
https://github.com/steve71/MAX31856
to check the hardware and connections.
This is working:

read.py
#!/usr/bin/python
import max31856
csPin = 8
misoPin = 9
mosiPin = 10
clkPin = 11
max = max31856.max31856(csPin,misoPin,mosiPin,clkPin)
thermoTempC = max.readThermocoupleTemp()
thermoTempF = (thermoTempC * 9.0/5.0) + 32
print "Thermocouple Temp: %f degF" % thermoTempF
juncTempC = max.readJunctionTemp()
juncTempF = (juncTempC * 9.0/5.0) + 32
print "Cold Junction Temp: %f degF" % juncTempF

./read.py
Thermocouple Temp: 78.898438 degF
Cold Junction Temp: 80.206250 degF

So it looks like the hardware and connections are ok.

[dennyfmn]

More information:
I bought a MAX31855 to round out the test capabilities. With the MAX31855 on spi0:0 and MAX6675's on spi0:1 and spi1:0, they all read correctly on both kernel 5.4 and 5.9.

/boot/config.txt
dtparam=spi=on
dtoverlay=spi1-1cs
dtoverlay=maxtherm,spi1-0,max6675
dtoverlay=maxtherm,spi0-1,max6675
dtoverlay=maxtherm,spi0-0,max31855

ls -l /sys/bus/iio/devices/
lrwxrwxrwx 1 root root 0 Nov 1 12:08 iio:device0 -> ../../../devices/platform/soc/20204000.spi/spi_master/spi0/spi0.0/iio:device0
lrwxrwxrwx 1 root root 0 Nov 1 12:08 iio:device1 -> ../../../devices/platform/soc/20204000.spi/spi_master/spi0/spi0.1/iio:device1
lrwxrwxrwx 1 root root 0 Nov 1 12:08 iio:device2 -> ../../../devices/platform/soc/20215080.spi/spi_master/spi1/spi1.0/iio:device2

./readall.py
Max31855-0:0: 21.15 Max6675-0:1 27.00 Max6675-1:0 25.88
Max31855-0:0: 23.27 Max6675-0:1 29.25 Max6675-1:0 28.46
Max31855-0:0: 23.48 Max6675-0:1 29.70 Max6675-1:0 28.95

When I substitute the MAX31856 for the MAX31855 on spi0:0 (including connecting SDO) there is no file for the MAX31856 in /sys/bus/iio/devices/. Same results as shown above in /sys/bus/spi/.

The MAX31856 works fine with a bit bang python driver as shown above.

[pelwell]

You clearly know what you're doing and have the device wired up correctly, so this is a software issue. You've shown that the overlay has been applied (which can be confirmed by looking at the output of sudo vcdbg log msg), but is there any evidence that the kernel has attempted to load the driver? What do the following commands return?

$ uname -a
$ dmesg | grep -i -E "(spi|max)"
$ lsmod | grep max
# N.B. this next line empties the current kernel log
$ sudo dmesg -C
$ sudo modprobe max31856
$ dmesg

[dennyfmn]

Hi Phil, There is a clue here, response to your questions: root@surfacemnt:~# uname -a Linux surfacemnt 5.9.1+ #1355 Mon Oct 19 14:10:47 BST 2020 armv6l GNU/Linux root@surfacemnt:~# dmesg | grep -i -E "(spi|max)" [ 0.000091] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns [ 0.060374] pid_max: default: 32768 minimum: 301 [ 0.080648] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.106316] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 1.981617] workingset: timestamp_bits=14 max_order=17 bucket_order=3 root@surfacemnt:~# lsmod | grep max maxim_thermocouple 16384 0 industrialio_triggered_buffer 16384 1 maxim_thermocouple industrialio 73728 3 maxim_thermocouple,industrialio_triggered_buffer,kfifo_buf root@surfacemnt:~# dmesg -C root@surfacemnt:~# modprobe max31856 modprobe: FATAL: Module max31856 not found in directory /lib/modules/5.9.1+ root@surfacemnt:~# dmesg root@surfacemnt:~# (nothing) Why did modprobe fail? I updated from kernel 5.4 to 5.9 with BRANCH=next rpi-update as directed Attempting to locate the kernel module: root@surfacemnt:~# updatedb root@surfacemnt:~# locate max31856 /root/max31856 /root/max31856/max31856.py /root/max31856/max31856.pyc /root/max31856/read.py /usr/local/src/MAX31856/Adafruit_Python_MAX31856/Adafruit_MAX31856/max31856.py /usr/local/src/MAX31856/Adafruit_Python_MAX31856/env_py3/lib/python3.7/site-packages/Adafruit_MAX31856/__pycache__/max31856.cpython-37.pyc /usr/local/src/MAX31856/Adafruit_Python_MAX31856/env_py3/lib/python3.7/site-packages/Adafruit_MAX31856/max31856.py (The kernel module was not found) Thanks! Denny

[pelwell]

The obvious explanation for those symptoms is that the modules haven't been built and/or installed properly. Is there anything in the indicated modules directory (/lib/modules/5.9.1+)?

[dennyfmn]

cd /lib/modules/5.9.1+
ls -l

drwxr-xr-x 11 root root 4096 Oct 23 14:07 kernel
-rw-r--r-- 1 root root 556650 Oct 23 14:07 modules.alias
-rw-r--r-- 1 root root 582763 Oct 23 14:07 modules.alias.bin
-rw-r--r-- 1 root root 12946 Oct 23 14:07 modules.builtin
-rw-r--r-- 1 root root 23238 Oct 23 14:07 modules.builtin.alias.bin
-rw-r--r-- 1 root root 13910 Oct 23 14:07 modules.builtin.bin
-rw-r--r-- 1 root root 70618 Oct 23 14:07 modules.builtin.modinfo
-rw-r--r-- 1 root root 190979 Oct 23 14:07 modules.dep
-rw-r--r-- 1 root root 264199 Oct 23 14:07 modules.dep.bin
-rw-r--r-- 1 root root 324 Oct 23 14:07 modules.devname
-rw-r--r-- 1 root root 63386 Oct 23 14:07 modules.order
-rw-r--r-- 1 root root 380 Oct 23 14:07 modules.softdep
-rw-r--r-- 1 root root 251266 Oct 23 14:07 modules.symbols
-rw-r--r-- 1 root root 306803 Oct 23 14:07 modules.symbols.bin

find . -name max -print

./kernel/drivers/rtc/rtc-max6900.ko
./kernel/drivers/rtc/rtc-max6902.ko
./kernel/drivers/media/tuners/max2165.ko
./kernel/drivers/power/supply/max17040_battery.ko
./kernel/drivers/iio/temperature/maxim_thermocouple.ko
./kernel/drivers/net/wimax
./kernel/net/wimax
./kernel/net/wimax/wimax.ko
./kernel/sound/soc/codecs/snd-soc-max98357a.ko

Checking the alias file:
cat modules.alias | grep max
gets many hits, but

cat modules.alias | grep 31856
returns nothing

Checking the 31855
cat modules.alias | grep 31855 | wc -l
24

So it appears that the 31856 was not compiled into this kernel.

[pelwell]

Our standard defconfigs don't enable the MAX31856 driver, so it's not going to work using one of our builds. I can and will add the module to future builds, but the quickest way forward for you is to build your own kernel, adding CONFIG_MAX31856=m to the configuration.

[dennyfmn]

Hmmm...

I haven't compiled a kernel in a long time. Since I have a work-around for my project with the bit-bang python driver, I think I'll wait for it to be included in the next update. If you would be so kind as to notify me when that is available, I'll be happy to test it.
If that's hard for you to do, how can I keep track of when a new version is available?

Thank you so much for your help.

[pelwell]

I think I'll wait for it to be included in the next update.

Of course. The commit is in rpi-5.9.y now, and I'd expect a push to the next branch in the next few days. My intention is to post an update here when that happens, but you'll find a list of commits and what goes into them here: https://github.com/raspberrypi/firmware/commits/next

[dennyfmn]

I updated the kernel today and the max31856 seems to work fine.

uname -a
Linux surfacemnt 5.9.3+ #1364 Wed Nov 4 11:09:36 GMT 2020 armv6l GNU/Linux

With /boot/config.txt
dtoverlay=maxtherm,spi1-0,max6675 (shows up as iio:device2)
dtoverlay=maxtherm,spi0-1,max6675 (shows up as iio:device0)
dtoverlay=maxtherm,spi0-0,max31856 (shows up as iio:device1)

cd /sys/bus/iio/devices/iio:device1
cat in_temp_raw
3083
cat in_temp_scale
7.812500
cat in_temp_oversampling_ratio
1
cat in_temp_thermocouple_type
K

Calculated temperature rounded to 2 places:
24.09 C

ls -l
-r--r--r-- 1 root root 4096 Nov 6 10:56 dev
-r--r--r-- 1 root root 4096 Nov 6 10:56 fault_oc
-r--r--r-- 1 root root 4096 Nov 6 10:56 fault_ovuv
-rw-r--r-- 1 root root 4096 Nov 6 10:56 in_temp_ambient_raw
-rw-r--r-- 1 root root 4096 Nov 6 10:56 in_temp_ambient_scale
-rw-r--r-- 1 root root 4096 Nov 6 10:56 in_temp_filter_notch_center_frequency
-rw-r--r-- 1 root root 4096 Nov 6 10:56 in_temp_oversampling_ratio
-rw-r--r-- 1 root root 4096 Nov 6 10:48 in_temp_raw
-rw-r--r-- 1 root root 4096 Nov 6 10:48 in_temp_scale
-rw-r--r-- 1 root root 4096 Nov 6 10:56 in_temp_thermocouple_type
-r--r--r-- 1 root root 4096 Nov 6 10:56 name
lrwxrwxrwx 1 root root 0 Nov 6 10:56 of_node -> ../../../../../../../../firmware/devicetree/base/soc/spi@7e204000/maxtherm@0
drwxr-xr-x 2 root root 0 Nov 6 10:56 power
lrwxrwxrwx 1 root root 0 Nov 6 10:56 subsystem -> ../../../../../../../../bus/iio
-rw-r--r-- 1 root root 4096 Nov 6 10:45 uevent

Questions:
Is there a way to predetermine the order that the devices show up in the /sys/bus/iio/devices/ tree? Until now, they seemed to be in reverse order as they were defined in /boot/config.txt.

Once you figure out which order they ended up in /sys/bus/iio/devices/ are they guaranteed to show up in that order on every reboot?

Edit:
I have rebooted and now device0 and device1 are switched.

Thanks for all your help!