STICKY:I2C, SPI, I2S, LIRC, PPS, stopped working? Read this.

[Bazzler53]

All fascinating stuff but as a novice this is all flew over my head. Since recently upgrading my NOOBS installation to v1.3.11 my Piand Bash no longer works. This seems to be associated with the i2c issues mentioned in this thread. However, I am getting error messages related to Could not resolve mirrordirector.raspbian.org when trying to get the i2c tools. I also get error messages telling the i2c group does not exist. I have tried the suggestions here but believe I shall have to resort to an earlier iteration of the kernel. The instructions to doso posted here make absolutely no sense to me so I am unable to try that route. Surely there must be a simple way to roll back to an earlier version of Raspbian so that I can get my PiandBash working again?

Please help me as I am about to lose what little hair I have remaining!

[PhilE]

The inability to resolve mirrordirector.raspbian.org sounds like the most important problem. Do you have any internet connectivity at all? Which LAN interface are you using? If it's a WiFi dongle, which model?

With regards to the Pi&Bash board, it looks like you need i2c and spi. Have you tried just adding:

Code: Select all

dtparam=i2c_arm=on,spi=on

to your config.txt and rebooting? You can also use raspi-config to enable these interfaces and manage the blacklisting and module loading - it's under "Advanced Options".

[DougieLawson]

Being unable to resolve domains to IP addresses is easily fixed with
sudo sh -c 'echo "nameserver 8.8.8.8" >> /etc/resolv.conf'

Assuming you have a good connection to 8.8.8.8
ping -c3 8.8.8.8
to test that.

[Bazzler53]

Thanks both. I too thought the resolving the mirror was fundamental to my problem. However, Pinventor (Mr PiandBash) suggested it could be a cache problem. So I did apt-cache policy i2c-tools i2c-tools and everything began working again. The resolving mirror problem went away and the remainder of the modules I needed installed fine. There is a small residual problem to fix but that seems to be within the demo script for the PiandBash which should be a case of editing (the spidev module can't be found now so the demo script fails).

As to your suggestions the Internet connect is over wifi which is solid, I use a Pi Hut dongle which has worked perfectly out of the box for months. I had already enabled i2c and spi through rpi-config. I had tried the dtparam settings in config but none of those made a difference to my original problem. But the cache route seems to have worked.

Anyway, as people have said Rpi is about learning and I am doing that in spades - just at a much lower level than I anticipated. It's been a long time since I played around down here, in fact it was probably back in the days of a Motorola 6500 in machine code!

Thanks for all the suggestions and advice anyway. Filing it all away for the future.

[PeterO]

[This is getting a bit off-topic. Perhaps you would like to create a DT Q&A thread.]

I have done this....
http://www.raspberrypi.org/forums/viewt ... 44&t=99784
PeterO

[texy]

Hi,
I can't seem to get I2C working on my B+ for a DS3231 RTC. I think I have the config's right, running the latest kernel :

Code: Select all

pi@raspberrypi ~ $ sudo uname -a
Linux raspberrypi 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux

Code: Select all

pi@raspberrypi ~ $ lsmod
Module                  Size  Used by
snd_bcm2835            21342  0
snd_pcm                93100  1 snd_bcm2835
snd_seq                61097  0
snd_seq_device          7209  1 snd_seq
snd_timer              23007  2 snd_pcm,snd_seq
snd                    67211  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
rtc_ds1307             10347  0
spi_bcm2708             6018  0
i2c_bcm2708             6200  0
8192cu                569633  0
uio_pdrv_genirq         3666  0
uio                     9897  1 uio_pdrv_genirq

Code: Select all

pi@raspberrypi ~ $ dmesg|grep i2c
[    5.996547] bcm2708_i2c_init_pinmode(1,2)
[    6.147769] bcm2708_i2c_init_pinmode(1,3)
[    6.355542] bcm2708_i2c 20804000.i2c: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100000)
pi@raspberrypi ~ $

config.txt :

Code: Select all

dtparam=spi=on
dtparam=i2c=on
dtoverlay=ds1307-rtc

However i2cdetect brings up an error :

Code: Select all

pi@raspberrypi ~ $ sudo i2cdetect -y 1
Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory
pi@raspberrypi ~ $

Any idea's?
Texy

[notro]

I think you need to load 'i2c-dev' as well.
i2c-dev provides userpace access to i2c.

[PhilE]

sudo modprobe i2c-dev

Device Tree causes the low level driver module to be loaded, but not the layered driver.

[texy]

Thank you Notro and Phil. Just getting to grips with how Device Tree works. All working OK now.
Texy

[XploD]

To avoid opening new topic, I'll ask here because it's related to LIRC. How does your remotes work and which remote/sensor do you use? I connected a sensor from an old DVD player to Pi and installed LIRC. It's working but not like it should: I have to press multiple times and experiment with remote direction to get the Pi receive the signal, it's going on my nerves. I tried with two different remotes and I tried with new batteries but still nothing. Is it beacuse of my old sensor or this is how LIRC works? Because, I want it to work like with any other TV/Hi-Fi remote, I don't want to press multiple times to get something (I'll be using the remote with my Java app to play/pause online radio, change volume and stations).

I'm testing it with "irw" and with my own Java app, results are the same. I even tried my air conditioning's remote and it works with "mode2 -d /dev/lirc0" but when I run "irrecord -d /dev/lirc0 ~/lircd.conf" it won't work anymore. And when in mode2, all remotes are working fine, it reacts on every key press. I'm using this tutorial: http://ozzmaker.com/2013/10/24/how-to-c ... ir-remote/

I suspect that it's the sensor that is causing trouble but I want to be sure before ordering new one.

[jsavage]

All,
I was bitten by this issue when I tried sudo apt-get upgrade in an attempt to troubleshoot a separate issue and I then made the mistake of believing that it was something I had just done that was now preventing all my DS18B20 temperature sensors from working. I only found the reason and the solution when I came across this thread with assistance from google. I suspect that there will people chasing their tails about this for weeks if not months but in the meantime thanks to all those who have contributed to this thread.

That said, it is a timely reminder that upgrades can break application software that has previously been tested. What can we learn from this? Is there is more that we as a community could have done to find out about and communicate the content of changes that will be made when an upgrade is next executed. I am aware that there is a simulate option (-s) for update and upgrade but I have just tried that on another pi running 3.12.28+ kernel and the output would certainly not have alerted me to this issue. I am aware that there is a readme file on this but again, I am not sure how I would have found that without first encountering the issue and then finding this thread.

So, I wonder, was anyone prepared for this one? If so, how did you hear about it?

James

[texy]

* Errm, "w1-gpio"?
Slightly more complicated. If you require the external pullup pin, use:
"dtoverlay=w1-gpio-pullup,gpiopin=<x>,extpullup=<y>"
otherwise use:
"dtoverlay=w1-gpio,gpiopin=<x>"
(where <x> and <y> are GPIO pins, obviously).
If you are using the parasitic power (power over data, 2-wire) mode, add ",pullup=1" (or ",pullup=on")

Where can I read more about this, as I am confused. If I have a physical pull-up resistor fitted, which option should I chose?
I expect the answer to be "dtoverlay=w1-gpio,gpiopin=<x>", but if I chose to not fit a resistor, does the other option enable you to use one of the other GPIO pins to act as the pull-up ? I ask this as I noticed in the boot up log that GPIO pin 5 is the default choice if no GPIO pin is set when using the "dtoverlay=w1-gpio-pullup,gpiopin=<x>" option.
Texy

[PhilE]

To be honest, I've never really understood that feature because I've never seen a usage scenario. The code describes it as an "external pullup enable" pin. You could conceivably (remember, I'm a software engineer, so it's probably best not to try this) connect your pull-up resistor to that pin, but you would have to take care to leave the pin floating when you didn't want to use this feature.

Having said that, I didn't want to remove a feature that people might be relying on, hence w1-gpio-pullup.

[Framb00s]

This is all very confusing, my lirc (on pin 31) stopped working after an apt-get update and upgrade.

I followed the text and tried
dtoverlay=lirc-rpi,gpio_in_pin=31,gpio_in_pull=high
it didn't worked
because I'm not shure if the pull up has to be high or low I tried
dtoverlay=lirc-rpi,gpio_in_pin=31,gpio_in_pull=low
still didn't worked
dtoverlay=lirc-rpi,gpio_in_pin=31
still didn't worked

Scrolling down the value seems to be
gpio_in_pull             Pull up/down/off on the input pin
                                 (default "down")
so should it be gpio_in_pull=down ??? or high??? or off???

(the most frustating is the fact that the RPI's of both my grandsons stopped working too and I cannot help them yet)

[PhilE]

Are you only using the input feature? The shipping Raspbian release probably still has broken lirc output.

What did you used to have in your /etc/modules? If you just have a sensor, such as the TSOP4838, wired directly to GPIO31, GND and 3V3, then all you should need to supply is the gpio_in_pin parameter.

Errrm, hang about, GPIO 31 isn't connected to the IDC pins. If you mean GPIO 6, which is connected to pin 31, then try:

Code: Select all

dtoverlay=lirc-rpi,gpio_in_pin=6

If this ever worked for you, and it sounds as though it did, then you must have known this once and put it in your /etc/modules (or /etc/modprobe.d/<something>.conf). I didn't change the name of the module parameters, just exposed them as DT parameters instead, but I can see how the "_pin" could be confusing.

[Framb00s]

Hello,


I use pin GPIO31 on P5 pin 6 + GND and 3,3V
When I put "device_tree=" in config.txt my lirc work.
But if I understand it well, if I want to keep using lirc in the future, I should use the device tree.

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

snd-bcm2835
lirc_dev
lirc_rpi gpio_in_pin=31

When I change my config.txt settings to
#lirc settings
dtoverlay=lirc-rpi,gpio_in_pin=31
#device_tree=
and do a "sudo reboot" the lirc does not work anymore

[PhilE]

Thank you for mentioning P5 - that really wasn't obvious. Now that I know that it seems like what you are doing ought to work.

Can you capture the relevant portion of the dmesg output for both cases, and then we can compare them?

[Framb00s]

Thank you for the answer
I got these results with working lirc and config.txt with
#lirc settings
#dtoverlay=lirc-rpi,gpio_in_pin=31
device_tree=

sudo reboot

pi@raspberrypi ~ $ dmesg | grep -i lirc
[ 14.986442] lirc_dev: IR Remote Control driver registered, major 247
[ 15.137673] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[ 16.108027] lirc_rpi: auto-detected active low receiver on GPIO pin 31
[ 16.111002] lirc_rpi lirc_rpi.0: lirc_dev: driver lirc_rpi registered at minor = 0
[ 16.115666] lirc_rpi: driver registered!
[ 17.988273] input: lircd as /devices/virtual/input/input0
pi@raspberrypi ~ $

with config.txt
#lirc settings
dtoverlay=lirc-rpi,gpio_in_pin=31
#device_tree=

sudo reboot

pi@raspberrypi ~ $ dmesg | grep -i lirc
[ 4.644300] lirc_dev: IR Remote Control driver registered, major 246
[ 4.755250] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.818292] lirc_rpi: auto-detected active low receiver on GPIO pin 31
[ 5.821505] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 5.826328] lirc_rpi: driver registered!
[ 9.156289] input: lircd as /devices/virtual/input/input0
[ 10.399177] CPU: 0 PID: 412 Comm: lircd Tainted: G C 3.18.7+ #755
[ 10.524022] [<c00612ac>] (request_threaded_irq) from [<bf01dab4>] (set_use_inc+0x44/0xd8 [lirc_rpi])
[ 10.529709] [<bf01dab4>] (set_use_inc [lirc_rpi]) from [<bf016bf8>] (lirc_dev_fop_open+0xe4/0x208 [lirc_dev])
[ 10.535437] [<bf016bf8>] (lirc_dev_fop_open [lirc_dev]) from [<c013eb20>] (chrdev_open+0xf4/0x1d8)
pi@raspberrypi ~ $

I did the dmesg command after immediately after startup and testing the lirc (works with my internet radio)
This is going far beyond my Linux knowledge.

[PhilE]

Hmm, something has clearly gone wrong.

I'm going to have to try and reproduce this on Monday, but just in case it turns out to be some peculiarity of your setup it would be helpful If you could show me the missing lines around this point:

Code: Select all

[ 10.399177] CPU: 0 PID: 412 Comm: lircd Tainted: G C 3.18.7+ #755
[ 10.524022] [<c00612ac>] (request_threaded_irq) from [<bf01dab4>] (set_use_inc+0x44/0xd8 [lirc_rpi])

It probably starts with a "BUG" or "WARN", and usually includes cut marks.

[PhilE]

@Framb00s, I can see what is going wrong here - the interrupt is being enabled and triggered before the handler is registered - and I'm working on a fix.

[PhilE]

The blurb and README at the top of this thread have been updated, as has the main documentation here. Highlights include:

• * The introduction of a generic i2c-rtc overlay - the old individual overlays are deprecated and will be removed from future releases.
  * The BMP085/180 barometric pressure and temperature sensor has an overlay.
  * The improved support for the board-specific I2C aliases (i2c/i2c_arm and i2c_vc) is described.
  * Multi-target parameters and 8-, 16- and 64-bit parameters are explained.

[meltwater]

Hopefully a quick question about device trees:
I was wondering if the lines that we need to put into config.txt (i.e. dtparam=i2c,i2s) can be put in separate files, and referenced by config.txt.
For instance, refer to a file that can be added or removed which enabled/disables i2c etc. I take it could be done using a .dts/.dtb file, or that an over complicated way to do it (if even supported)?

Thanks, still getting to grips with the whole device tree thing.
Tim.

[PhilE]

You could do that, if you really want to, in fact originally this was how the interfaces were going to be managed. All that is required is a tiny overlay that sets the "status" property for the relevant interface nodes to "okay". Here is one for i2c:

Code: Select all

// Enable the ARM-side i2c device
/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2708";

	fragment@0 {
		target = <&i2c_arm>;
		__overlay__ {
			status = "okay";
		};
	};
};

If you replace "<&i2c_arm>" with "<&i2s>" and "<&spi0>" you get the other two.

And here are the .dtbs:

Code: Select all

H4sIAOY+7FQAA+3VS0rDUBQG4FNfUKSgggMHSpw5sHrzLh25k3AT0xps2pCkYhcluALX4AocOxF3
IJ60NyrF2kEf0vJ/cLiBe/IgOT8Ju9LvhPXICOoyjeu9uzDtyMHFde7T3AjmOFax6q4tfq5Dlq6T
bliuKUxHGAYJ3TJtmzQxv0eYrJ/lMtU0Sm6izl990/ZX1HPt442oUuXDBtcr1xnXPteeajnlevzl
1IpaN7lqxYGfBvG5H8SGKxplTyuV7Tjs5lfiq3eLa/fl4em92Pc8NXKeV+5vcx30buVAXWNDFfe2
ovt+ko1ah72HXEeX3zdp8sdsh3lTjJ1bDXpxIvOIZ51GLcTfPe9nxJPv8eTP8g5XWVjmP1tM9gtT
8y/sMv+ucG3Ov+mYFvK/DCr/ReYm5f+Y1jv/2Szvb9Wp/GdJ9J/5d8b+/6bLC/K/BCr/OzQ5/ye0
zvnnyV/KnAEAAAAAAAAAAAAAAAAALNgnEwTpUwAoAAA=

To extract them, copy this into a file and type:

Code: Select all

base64 -d <file> | (cd /boot/overlays; sudo tar zxvf -)

where <file> is the name of your file.

You can then add this to your config.txt:

Code: Select all

dtoverlay=enable-i2c-arm
dtoverlay=enable-i2s
dtoverlay=enable-spi

Simply rename the ones you don't want to use. The loader will complain about the missing ones, but in a place you won't see unless you go looking.

We are investigating the runtime manipulation of the Device Tree, which would allow you to run:

Code: Select all

dtoverlay enable-i2c-arm

from the shell, but that is still some way off.

[meltwater]

Excellent, many thanks for the examples and explanation!
I shall give it a go as it will be very helpful for me to understand the process a little better and these examples are perfect for doing so.

For those of us who have not used them before, it all takes a little getting used to.

[texy]

Here is another method of producing the dtb file from dts :
https://github.com/notro/fbtft/wiki/FBTFT-RPI-overlays

Texy