Page 1 of 1

IO0 and IO1 signals

Posted: Sun Nov 06, 2016 8:19 pm
by jrychter

I've been wondering — are the IO0 and IO1 signals actually used? I am designing a board with an RPI Compute Module, and routing these signals across the board is a bit of a nuisance. When the camera is up and running, it seems these lines always stay high.

I don't know what they are supposed to do — I've seen mentions of flash control?

Is it possible to avoid connecting them altogether? Can I disconnect those lines, or use pullups on both sides instead of connecting the signals?


Re: IO0 and IO1 signals

Posted: Tue Nov 08, 2016 1:10 pm
by jrychter
Responding to myself — I checked, and IO0 is brought high during powerup, it always stays high. It seems to be an ENABLE signal that keeps the camera turned on. IO1 goes high while the camera is actually active (recording video).

It seems to me that I can safely just use pullups for both of those signals, and the RPi v2 camera module will work just fine.

Re: IO0 and IO1 signals

Posted: Tue Nov 08, 2016 1:48 pm
by 6by9
That doesn't sound right, but will depend on how you've wired through the CMIO and your dt-blob.bin.

CAM_IO0 (referred to as CAM_GPIO on some of the other Pi schematics) is used to control the shutdown line on the sensor. It's whichever pin you've defined as pin_define@CAMERA_0_SHUTDOWN in dt-blob.dts
CAM_IO1 (referred to as CAM_CLK on some of the other Pi schematics) was connected to the LED on the V1 camera module. It isn't used on the V2 camera module. It's whichever pin you've defined as pin_define@CAMERA_0_LED in dt-blob.dts

Both of them should be taken high at the point of use (LED line first, then shutdown, and dropped in the opposite order).
Using a pull up will increase your power consumption slightly as the camera will always be powered. It also prevents the GPU doing a power cycle on the sensor, so if it does lock up then you're stuck.

Re: IO0 and IO1 signals

Posted: Wed Nov 09, 2016 8:45 am
by jrychter
Hey 6by9 — thanks for the explanation! Ok, so I went ahead and double-checked with a logic analyzer. Here's what I'm seeing:

* IO0 line starts low, then goes high during bootup for about 6ms, during which time there is some I2C chatter. Then the line goes low again.

* IO0 goes high when I actually start capturing video, then goes low again.

This is all good and exactly matches what you are saying. What I don't understand however:

* IO1 starts high and always stays high. Looks like it has a pullup, weaker than my I2C, because it goes high slightly later than I2C lines, but still. I don't think this matters much, as it isn't used anyway in v2.1 camera boards. I will not connect it at all.

* There are I2C transactions when IO0 is low. And something (device 0xc8/0xc9, 0x64 in 7-bit) is definitely responding.

I thought that instead of pullups I'd still allow IO0 through, and use it to control the enable signal of a level shifter, but why are there I2C transactions when IO0 is low? And what responds, if IO0 is supposed to control the voltage regulators on the camera board?

I verified this with both camera ports, exact same behavior. I also checked my dt-blob, it seems correct. I am using the same pins and the same blob that the CM IO developer board uses.

PS: sorry, I got the IO0 and IO1 lines mixed up in the previous post.

Re: IO0 and IO1 signals

Posted: Mon Nov 14, 2016 11:05 am
by 6by9
I2C address 0x64 is not the sensor itself. The IMX219 sensor is on address 0x10.
Yes there will be transactions to 0x64 before the IO0 is brought up as that device is powered directly off the 3V3 power rail.
IMX219 has multiple regulators to deliver the required supply rails to the sensor. Those regulators are controlled off IO0 - I have the schematic in front of me.

At a guess something during boot is using the camera_info component to identify the attached cameras. Probably either "vcgencmd get_camera", or the probe of bcm2835-v4l2. That accounts for your 6ms chatter. Obviously the sensor has to also be powered up when it is wanted.

Re: IO0 and IO1 signals

Posted: Sat Nov 26, 2016 11:37 am
by jrychter
Thanks for all the info. I decided to terminate IO1 with a pullup, which shouldn't hurt anything, and properly level-shift the IO0 line so that it works as intended.