Using the other i2c bus hangs raspistill

[rayjoh]

There is some conflict between the i2c buses.

The shell script can run for hours with no problem if I do not access the RTC clock http://www.adafruit.com/products/264. raspistill hangs if I run the command "hwclock -r" a few times. The camera LED is on.

raspistill also hangs if I run python scripts to access a Pi Plate http://www.adafruit.com/products/1115 or a TMP102 https://www.sparkfun.com/products/9418

I have been using one pi model A and one model B with two different power sources.
One 2A power supply connected to a USB hub. The pi is powered from the hub to the mikrousb port. TP1-TP2 is 4.9V. Also tested with a 12v car battery and LM2596
No keyboard and screen is connected, I login via ssh to them.

I did a fresh install of 2013-05-25-wheezy-raspbian on a second SD-card. No difference.

The script that I use to test raspistill

Code: Select all

while /bin/true ; do      
    date     
    raspistill -n -t 100 -e jpg -o - >  /dev/null
    sleep 1
done

[jamesh]

Perhaps not related to the issue but you probably need to have a bigger delay between each invocation of raspistill - I doubt it can run up, capture then shutdown that fast and keep itself clean. I'd also use a longer -t value as well, I don't think 100 is enough for the exposure to have stabilised.

[rayjoh]

Perhaps not related to the issue but you probably need to have a bigger delay between each invocation of raspistill - I doubt it can run up, capture then shutdown that fast and keep itself clean. I'd also use a longer -t value as well, I don't think 100 is enough for the exposure to have stabilised.

A new test.
I run this command in one terminal window

Code: Select all

for x in 1 2 3 4 5 6 7 8 9 ; do hwclock -r ; done

And this in another window

Code: Select all

raspistill -n -t 3000 -e jpg -o image.jpg

raspistill hangs forever in.

Code: Select all

root@pi4:~# strace -p 3546
Process 3546 attached - interrupt to quit
futex(0xb6f01390, FUTEX_WAIT_PRIVATE, 0, NULL

[jamesh]

Wasn't really expecting it to help, but worth a punt. This one needs to go to Dom I think. There should be no interference between the two AFAIK.

[jamesh]

Consensus is maybe a fault in the Arm side I2C driver that its may be reseting the peripheral, or maybe bad clocking somwhere. Someone who knows more about it will have to look at it I think! Hopefully Dom will be able to comment.

My own thoughts are perhaps that the Arm side driver has no idea the I2C is being used by the GPU, so happily does a reset since its thinks its the only user. No idea how to test that though.

[jamesh]

Dom's taken a quick look and the driver doesn't seem to be doing the wrong thing.

Anyone know if the source to hwclock is available anywhere? That might be the culprit.

[Gert van Loo]

This has gone up the chain of people who might know and landed on my desk.
I will have to look into this but I can't do that right now as I have a few other more important issues to resolve.
I CAN say that all the I2C channel are hardware-independent. That is: the chip has three totally individual instantiated I2C blocks.
AFAIK the source of the I2C clock is the system bus clock, not the general clock manager.

[tasanakorn]

In my case, MPU6050 gyro+accel I2C.

Might be

https://github.com/raspberrypi/linux/issues/243

[tasanakorn]

Hi,
Good news. Finally, I can work around this problems (at least in my case).

Just unbind i2c bus 0 from linux i2c driver.

Code: Select all

sudo -s
echo bcm2708_i2c.0 > /sys/bus/platform/drivers/bcm2708_i2c/unbind

Now, I can mad pulling I2C and Camera simultaneously.


IMHO, conflict between Camera Driver (I2C-0 from GPU) and I2C linux kernel.

[dom]

Gert's given me a hwclock module. I can see the problem.

Basically there is a common I2C interrupt between the channels, and both I2C bus' handlers get called.
Because GPU is talking to camera on the "other" I2C bus, the arm eventually sees the "DONE" bit from a transaction and thinks it ought to respond.

This response results in either a panic when a null message pointer is dereferenced, or if it gets past that, then the resulting I2C responses will likely upset the camera.

I think @tasanakorn's unbind solution is actually the techically correct one.

I've also got a patch that makes I2C driver ignore interrupts if it has no outstanding messages, which also seems to fix it.

If anyone has an I2C device and ability to rebuild kernel, can you test this patch:
http://pastebin.com/z7G6tnHy

Firstly, does it break your current I2C usage?
Secondly does it continue to work when camera is active?

[rayjoh]

I have successfully built a new kernel and modules. raspistill survived my hwclock test.

Without the patch, I could run raspistill and pi plate for maximum 5 minutes. I am running a test with raspistill, Pi plate and tmp102 at the moment. Still running after 40 minutes.

Added: I aborted the test after 8 hours. The patch is OK for me.

[dom]

Added: I aborted the test after 8 hours. The patch is OK for me.

Thanks for report. I'll add the patch to kernel source.

[johntucker]

I to have this problem. I would like to know which of the two solutions in this chain is best. I would rather not have to rebuild the kernel so the unbind seems better but a better explanation would be helpful.

Thanks.

[jamesh]

I to have this problem. I would like to know which of the two solutions in this chain is best. I would rather not have to rebuild the kernel so the unbind seems better but a better explanation would be helpful.

Thanks.

You could try rpi-update - that may pull in the fix.

[johny]

Thanks for this thread - I had a fun time trying to work out why my Pi B rev 1 was hanging intermittently.

Since it's not explicitly stated here yet: Don't use other devices on i2c-0 while you're using the camera - it won't always work... The CSI has a control channel (CCI) which is on i2c-0.

On the newer revision boards this is much harder to do by accident since the i2c-0 pins got moved to P5.