From: kuntushi <kun...@ya...> - 2008-08-04 08:02:51
|
I've installed the most recent kernel onto my gumstix/verdex board, which from what I can gather has the i2c modules written by Dave already incorporated. But I have a few questions on setup, because I can't seem to get a response from my device. The i2c program itself just tells me the responses timed out. 1. Is the gumstix a master by default (or in the build on svn)? 2. Will both lines need the pull up resistors (I've tried with and without 4.3k resistors)? 3. Is two wire I2C fine? As in, just using SDA and SCL? 4. Dave's code is set to the /dev/i2c-0 device. Could it be possible that I somehow need the i2c-1 device, or is this not used? 5. If I am trying to read from the slave address 0x43, and read the register 0x0A, is the correct command "i2c 0x43 rd 0x0A"? I've tried playing around with a few things, and just can't seem to get a real response. Any help would be greatly appreciated. -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18807158.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2008-08-04 08:36:07
|
Hi, > I've installed the most recent kernel onto my gumstix/verdex board, which > from what I can gather has the i2c modules written by Dave already > incorporated. But I have a few questions on setup, because I can't seem to > get a response from my device. The i2c program itself just tells me the > responses timed out. > > 1. Is the gumstix a master by default (or in the build on svn)? Yes > 2. Will both lines need the pull up resistors (I've tried with and without > 4.3k resistors)? Yes. > 3. Is two wire I2C fine? As in, just using SDA and SCL? No - you also need a common ground. > 4. Dave's code is set to the /dev/i2c-0 device. Could it be possible that > I somehow need the i2c-1 device, or is this not used? i2c-1 is for communicating with the PMU chip on the verdex. i2c-0 is for the bus brought out on the hirose connector. > 5. If I am trying to read from the slave address 0x43, and read the > register 0x0A, is the correct command "i2c 0x43 rd 0x0A"? Looks right. Just double check the address. Linux uses a 7-bit address, which is in the upper 7-bits of the first byte. Many manufacturers specify the address as the whole byte, not just the 7-bits. > I've tried playing around with a few things, and just can't seem to get a > real response. Any help would be greatly appreciated. What device are you trying to talk to? -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: kuntushi <kun...@ya...> - 2008-08-04 23:50:07
|
Hi Dave, I'm trying to connect to an OmniVision camera chip (OV7720). The three wire I meant was another logic level, with a start and end transmission change. Just the two lines are fine for me (SDA and SCL), but I actually don't have a common ground between my circuits. Thanks for mentioning that. I'm actually using the 120-pin molex connector too, but it has the i2c lines on it. I assume they are connected to the ones on the hirose connector. I need the molex connector because of all the quick capture pins. I'll also keep the 7-bit addresses in mind and try apply it once I sort out a common ground. Thanks for the info. Dave Hylands wrote: > > Hi, > >> I've installed the most recent kernel onto my gumstix/verdex board, which >> from what I can gather has the i2c modules written by Dave already >> incorporated. But I have a few questions on setup, because I can't seem >> to >> get a response from my device. The i2c program itself just tells me the >> responses timed out. >> >> 1. Is the gumstix a master by default (or in the build on svn)? > > Yes > >> 2. Will both lines need the pull up resistors (I've tried with and >> without >> 4.3k resistors)? > > Yes. > >> 3. Is two wire I2C fine? As in, just using SDA and SCL? > > No - you also need a common ground. > >> 4. Dave's code is set to the /dev/i2c-0 device. Could it be possible >> that >> I somehow need the i2c-1 device, or is this not used? > > i2c-1 is for communicating with the PMU chip on the verdex. i2c-0 is > for the bus brought out on the hirose connector. > >> 5. If I am trying to read from the slave address 0x43, and read the >> register 0x0A, is the correct command "i2c 0x43 rd 0x0A"? > > Looks right. Just double check the address. Linux uses a 7-bit > address, which is in the upper 7-bits of the first byte. Many > manufacturers specify the address as the whole byte, not just the > 7-bits. > >> I've tried playing around with a few things, and just can't seem to get a >> real response. Any help would be greatly appreciated. > > What device are you trying to talk to? > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18821970.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: kuntushi <kun...@ya...> - 2008-08-09 10:48:14
|
Hi Dave, It seems to be 186kHz, quite higher than 100kHz. But either way, the chip should support it, so I'll leave the idea of changing the speed for now anyway, especially if it is hardware driven. Some OV chips do allow you to alter the address by changing certain pins, but this one does not. I have triple checked that, just to make sure I hadn't messed something up somewhere. As for the clock, I've checked that too. It's getting a nice 0 - 3.3V 24MHz square wave as its clock signal. That is the recommended "ideal" system clocking frequency. All the power inputs are the correct levels too (3.3V and 1.8V), and the whole system draws about 20mA, which means the chip is drawing current for something. I might just make a new board with a new chip... maybe the one I have is busted. I have 5 to play with anyway. That is unless you can think of anything else to try first? Dave Hylands wrote: > > Hi kuntushi, > >> Yeah, I've hooked it up through a CRO and checked the signals going back >> and >> forth. Unfortunately, my hardware doesn't seem to pull the line low in >> the >> 9th "Don't Care" bit. So no matter what command I try and send, the >> first >> phase is trying to just send to the slave address with a write command, >> gets >> no response in the 9th bit, and then that just repeats 5 more times. I >> was >> looking for the part where it waited for the 9th bit ot be pulled low >> before >> sending the 2nd phase (registry address), but couldn't find it. I also >> couldn't find where it told it to try 5 more times. What file is that >> code >> in? > > Waiting for the 9th bit is probably done in the hardware. > >> I was going to look at lowering the frequency of the data transfer to see >> if >> that helps. My chip is "meant" to be able to take up to 400kHz, but I >> will >> still try with something slower. I looked through your code and couldn't >> find where you define your speed of roughly 200kHz. Did you set that, or >> is >> that something built into the underlying protocols that you access? > > I believe that the HW supports 100 kHz and 400 kHz, and that it uses > 100 kHz by default. > > The PXA driver can be found in drivers/i2c/busses/i2c-pxa.c > > If you search for "retries" you'll find the 5 in a data structure. > > Does the chip have any pins to allow the address to be selected? Some > chips allow some of the least significant bits to be controlled by > tying pins low or high? > > Are you providing a valid clock to the OV7720? > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18903841.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: kuntushi <kun...@ya...> - 2008-08-12 00:29:57
|
Thanks for the info Richard. I don't think I'll need the analyser though, the CRO I have here does I2C analysing on it and I can see the clock and data lines nicely. It definitely seems that my camera chip isn't pulling the data line low. It seems like the gumstix is always asserting on that line though, so I'm wondering if maybe my pull ups aren't right or something like that. Assuming that the camera chip is working and there is a connection between the SDA and SCL lines, can anyone think of any other reason the slave wouldn't pull the data line low? Or even suggestions for trying to fix it. I'll try some higher pull ups and some other stuff now, but any other ideas would be greatly appreciated. rtstofer wrote: > > I would be surprised if the Verdex 'waited' for the 9th or ACK bit. It > expects that bit to be properly set at the next clock following the R/W > bit. If the data line isn't pulled low (ACK) then the controller > interprets the signal as a NAK and stops. Pretty consistent with what > you are seeing. > > Assuming the hardware is proper (I2C bus voltage, pull-up resistors, > connections, etc), about the only thing that can prevent the ACK bit is > an address mismatch. > > If you can see the transaction on a scope, look at the 9th bit. If it > isn't pulled low, the Verdex sees a NAK. > > I have never had much success using the I2C bus without using a logic > analyzer. I use http://www.sump.org/projects/analyzer/ based on > http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD I built a > little logic level shifter PCB that plugs in to the S3 board so I could > use 5V signals with a 3.3V FPGA. > > I also have a little schematic for a 2 chip synchronizer that is used to > sync a scope as it detects the start and stop condition on the bus. I > haven't used the circuit but it seems like a neat design and a great > idea. At least the scope trace will line up with the start condition. > > After 3 different attempts to attach the schematic, I have given up. If > you need it, send me an email off-list and I will attach it to a Reply. > > My email address is: rstofer "AT" pacbell "DOT" net > > Richard > > -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18936203.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Harry J M. <hj...@ec...> - 2008-08-04 10:01:55
|
On Mon, 4 Aug 2008, Dave Hylands wrote: >> 3. Is two wire I2C fine? As in, just using SDA and SCL? > > No - you also need a common ground. > >> 4. Dave's code is set to the /dev/i2c-0 device. Could it be possible that >> I somehow need the i2c-1 device, or is this not used? > > i2c-1 is for communicating with the PMU chip on the verdex. i2c-0 is > for the bus brought out on the hirose connector. Which bus is connected to the tsc2003 on the consoleLCD-16? When I boot my Verdex it only creates /dev/i2c-1 and not /dev/i2c-0. This might be a problem with my 2.6.26 patches--and would explain why X is unhappy with me. >> 2. Will both lines need the pull up resistors (I've tried with and without >> 4.3k resistors)? > > Yes. If the tsc2003 is on /dev/i2c-0, will I need to add these resistors? -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: Harry J M. <hj...@ec...> - 2008-08-04 16:44:12
|
On Mon, 4 Aug 2008, Harry J Mason wrote: > Which bus is connected to the tsc2003 on the consoleLCD-16? When I boot my > Verdex it only creates /dev/i2c-1 and not /dev/i2c-0. > > This might be a problem with my 2.6.26 patches--and would explain why X is > unhappy with me. My fault--this is fixed now, and the touchscreen works. Does anyone know how to read the tsc2003 A2D inputs--ideally at the same time as using the touchscreen? I imagine I'll have to patch the kernel module myself :( -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: kuntushi <kun...@ya...> - 2008-08-05 02:15:13
|
Unfortunately I am getting an error that seems common. However, I've tried all the things other people have, and I still can't get it going. My error is: root@gumstix-custom-verdex:~$ i2c 0x21 rb 0x0A i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000007e0 ISR: 00000002 i2c: log: [00000446:000007e0] ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) ERROR: I2cReadByte failed: -1 The data sheet says "The device slave addresses are 0x42 for write and 0x43 for read". I've tried with the addresses 0x42, 0x43 and their 7-bit equivalent, 0x21 (as above). I've tried a few addresses around those numbers too, all to no avail. Both my SDA and SCL lines are at 3.3V and I have a common ground between my camera board and my verdex board. I have (which I don't think will matter because it uses a different address) turned off the tsc2003 module. From all the other posts I have checked, I don't think there was much else people did to finally get it working. Could it be because I am using the 120-pin molex connecter on the verdex board? Cheers. kuntushi wrote: > > Hi Dave, > > I'm trying to connect to an OmniVision camera chip (OV7720). The three > wire I meant was another logic level, with a start and end transmission > change. Just the two lines are fine for me (SDA and SCL), but I actually > don't have a common ground between my circuits. Thanks for mentioning > that. > > I'm actually using the 120-pin molex connector too, but it has the i2c > lines on it. I assume they are connected to the ones on the hirose > connector. I need the molex connector because of all the quick capture > pins. > > I'll also keep the 7-bit addresses in mind and try apply it once I sort > out a common ground. > > Thanks for the info. > > > Dave Hylands wrote: >> >> Hi, >> >>> I've installed the most recent kernel onto my gumstix/verdex board, >>> which >>> from what I can gather has the i2c modules written by Dave already >>> incorporated. But I have a few questions on setup, because I can't seem >>> to >>> get a response from my device. The i2c program itself just tells me the >>> responses timed out. >>> >>> 1. Is the gumstix a master by default (or in the build on svn)? >> >> Yes >> >>> 2. Will both lines need the pull up resistors (I've tried with and >>> without >>> 4.3k resistors)? >> >> Yes. >> >>> 3. Is two wire I2C fine? As in, just using SDA and SCL? >> >> No - you also need a common ground. >> >>> 4. Dave's code is set to the /dev/i2c-0 device. Could it be possible >>> that >>> I somehow need the i2c-1 device, or is this not used? >> >> i2c-1 is for communicating with the PMU chip on the verdex. i2c-0 is >> for the bus brought out on the hirose connector. >> >>> 5. If I am trying to read from the slave address 0x43, and read the >>> register 0x0A, is the correct command "i2c 0x43 rd 0x0A"? >> >> Looks right. Just double check the address. Linux uses a 7-bit >> address, which is in the upper 7-bits of the first byte. Many >> manufacturers specify the address as the whole byte, not just the >> 7-bits. >> >>> I've tried playing around with a few things, and just can't seem to get >>> a >>> real response. Any help would be greatly appreciated. >> >> What device are you trying to talk to? >> >> -- >> Dave Hylands >> Vancouver, BC, Canada >> http://www.DaveHylands.com/ >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18823346.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: zackbass <zac...@mi...> - 2008-08-05 04:31:44
|
I've been running into similar errors with my Robostix setup. As best as I can tell (which is not very well so please excuse me if I'm wrong) I2C seems broken on every build I tried (many). I spent a week wrestling with the thing before trying a Buildroot install for a long shot and having it work. http://www.nabble.com/Re%3A-i2c-Gumstix-to-Robostix-timeout-p18744070.html kuntushi wrote: > > Unfortunately I am getting an error that seems common. However, I've > tried all the things other people have, and I still can't get it going. > My error is: > > root@gumstix-custom-verdex:~$ i2c 0x21 rb 0x0A > i2c: error: exhausted retries > i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 > i2c: ICR: 000007e0 ISR: 00000002 > i2c: log: [00000446:000007e0] > ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) > ERROR: I2cReadByte failed: -1 > > The data sheet says "The device slave addresses are 0x42 for write and > 0x43 for read". I've tried with the addresses 0x42, 0x43 and their 7-bit > equivalent, 0x21 (as above). I've tried a few addresses around those > numbers too, all to no avail. > > Both my SDA and SCL lines are at 3.3V and I have a common ground between > my camera board and my verdex board. I have (which I don't think will > matter because it uses a different address) turned off the tsc2003 module. > From all the other posts I have checked, I don't think there was much else > people did to finally get it working. Could it be because I am using the > 120-pin molex connecter on the verdex board? > > Cheers. > > > kuntushi wrote: >> >> Hi Dave, >> >> I'm trying to connect to an OmniVision camera chip (OV7720). The three >> wire I meant was another logic level, with a start and end transmission >> change. Just the two lines are fine for me (SDA and SCL), but I actually >> don't have a common ground between my circuits. Thanks for mentioning >> that. >> >> I'm actually using the 120-pin molex connector too, but it has the i2c >> lines on it. I assume they are connected to the ones on the hirose >> connector. I need the molex connector because of all the quick capture >> pins. >> >> I'll also keep the 7-bit addresses in mind and try apply it once I sort >> out a common ground. >> >> Thanks for the info. >> >> >> Dave Hylands wrote: >>> >>> Hi, >>> >>>> I've installed the most recent kernel onto my gumstix/verdex board, >>>> which >>>> from what I can gather has the i2c modules written by Dave already >>>> incorporated. But I have a few questions on setup, because I can't >>>> seem to >>>> get a response from my device. The i2c program itself just tells me >>>> the >>>> responses timed out. >>>> >>>> 1. Is the gumstix a master by default (or in the build on svn)? >>> >>> Yes >>> >>>> 2. Will both lines need the pull up resistors (I've tried with and >>>> without >>>> 4.3k resistors)? >>> >>> Yes. >>> >>>> 3. Is two wire I2C fine? As in, just using SDA and SCL? >>> >>> No - you also need a common ground. >>> >>>> 4. Dave's code is set to the /dev/i2c-0 device. Could it be possible >>>> that >>>> I somehow need the i2c-1 device, or is this not used? >>> >>> i2c-1 is for communicating with the PMU chip on the verdex. i2c-0 is >>> for the bus brought out on the hirose connector. >>> >>>> 5. If I am trying to read from the slave address 0x43, and read the >>>> register 0x0A, is the correct command "i2c 0x43 rd 0x0A"? >>> >>> Looks right. Just double check the address. Linux uses a 7-bit >>> address, which is in the upper 7-bits of the first byte. Many >>> manufacturers specify the address as the whole byte, not just the >>> 7-bits. >>> >>>> I've tried playing around with a few things, and just can't seem to get >>>> a >>>> real response. Any help would be greatly appreciated. >>> >>> What device are you trying to talk to? >>> >>> -- >>> Dave Hylands >>> Vancouver, BC, Canada >>> http://www.DaveHylands.com/ >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18824428.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2008-08-08 15:13:45
|
Hi kuntushi, > Unfortunately I am getting an error that seems common. However, I've tried > all the things other people have, and I still can't get it going. My error > is: > > root@gumstix-custom-verdex:~$ i2c 0x21 rb 0x0A > i2c: error: exhausted retries > i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 > i2c: ICR: 000007e0 ISR: 00000002 > i2c: log: [00000446:000007e0] > ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) > ERROR: I2cReadByte failed: -1 > > The data sheet says "The device slave addresses are 0x42 for write and 0x43 > for read". I've tried with the addresses 0x42, 0x43 and their 7-bit > equivalent, 0x21 (as above). I've tried a few addresses around those > numbers too, all to no avail. 0x21 would be the correct 7-bit address for this case. > Both my SDA and SCL lines are at 3.3V and I have a common ground between my > camera board and my verdex board. I have (which I don't think will matter > because it uses a different address) turned off the tsc2003 module. From > all the other posts I have checked, I don't think there was much else people > did to finally get it working. Could it be because I am using the 120-pin > molex connecter on the verdex board? The exhausted retries message typically means that no device responded to the request. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: kuntushi <kun...@ya...> - 2008-08-09 03:19:49
|
Hi Dave, Yeah, I've hooked it up through a CRO and checked the signals going back and forth. Unfortunately, my hardware doesn't seem to pull the line low in the 9th "Don't Care" bit. So no matter what command I try and send, the first phase is trying to just send to the slave address with a write command, gets no response in the 9th bit, and then that just repeats 5 more times. I was looking for the part where it waited for the 9th bit ot be pulled low before sending the 2nd phase (registry address), but couldn't find it. I also couldn't find where it told it to try 5 more times. What file is that code in? I was going to look at lowering the frequency of the data transfer to see if that helps. My chip is "meant" to be able to take up to 400kHz, but I will still try with something slower. I looked through your code and couldn't find where you define your speed of roughly 200kHz. Did you set that, or is that something built into the underlying protocols that you access? Appreciate the help. Dave Hylands wrote: > > Hi kuntushi, > >> Unfortunately I am getting an error that seems common. However, I've >> tried >> all the things other people have, and I still can't get it going. My >> error >> is: >> >> root@gumstix-custom-verdex:~$ i2c 0x21 rb 0x0A >> i2c: error: exhausted retries >> i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 >> i2c: ICR: 000007e0 ISR: 00000002 >> i2c: log: [00000446:000007e0] >> ERROR: I2cTransfer: ioctl failed: Remote I/O error (121) >> ERROR: I2cReadByte failed: -1 >> >> The data sheet says "The device slave addresses are 0x42 for write and >> 0x43 >> for read". I've tried with the addresses 0x42, 0x43 and their 7-bit >> equivalent, 0x21 (as above). I've tried a few addresses around those >> numbers too, all to no avail. > > 0x21 would be the correct 7-bit address for this case. > >> Both my SDA and SCL lines are at 3.3V and I have a common ground between >> my >> camera board and my verdex board. I have (which I don't think will >> matter >> because it uses a different address) turned off the tsc2003 module. From >> all the other posts I have checked, I don't think there was much else >> people >> did to finally get it working. Could it be because I am using the >> 120-pin >> molex connecter on the verdex board? > > The exhausted retries message typically means that no device responded > to the request. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18901856.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2008-08-09 07:10:55
|
Hi kuntushi, > Yeah, I've hooked it up through a CRO and checked the signals going back and > forth. Unfortunately, my hardware doesn't seem to pull the line low in the > 9th "Don't Care" bit. So no matter what command I try and send, the first > phase is trying to just send to the slave address with a write command, gets > no response in the 9th bit, and then that just repeats 5 more times. I was > looking for the part where it waited for the 9th bit ot be pulled low before > sending the 2nd phase (registry address), but couldn't find it. I also > couldn't find where it told it to try 5 more times. What file is that code > in? Waiting for the 9th bit is probably done in the hardware. > I was going to look at lowering the frequency of the data transfer to see if > that helps. My chip is "meant" to be able to take up to 400kHz, but I will > still try with something slower. I looked through your code and couldn't > find where you define your speed of roughly 200kHz. Did you set that, or is > that something built into the underlying protocols that you access? I believe that the HW supports 100 kHz and 400 kHz, and that it uses 100 kHz by default. The PXA driver can be found in drivers/i2c/busses/i2c-pxa.c If you search for "retries" you'll find the 5 in a data structure. Does the chip have any pins to allow the address to be selected? Some chips allow some of the least significant bits to be controlled by tying pins low or high? Are you providing a valid clock to the OV7720? -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Richard T. S. <rs...@pa...> - 2008-08-09 14:30:29
|
I would be surprised if the Verdex 'waited' for the 9th or ACK bit. It expects that bit to be properly set at the next clock following the R/W bit. If the data line isn't pulled low (ACK) then the controller interprets the signal as a NAK and stops. Pretty consistent with what you are seeing. Assuming the hardware is proper (I2C bus voltage, pull-up resistors, connections, etc), about the only thing that can prevent the ACK bit is an address mismatch. If you can see the transaction on a scope, look at the 9th bit. If it isn't pulled low, the Verdex sees a NAK. I have never had much success using the I2C bus without using a logic analyzer. I use http://www.sump.org/projects/analyzer/ based on http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD I built a little logic level shifter PCB that plugs in to the S3 board so I could use 5V signals with a 3.3V FPGA. I also have a little schematic for a 2 chip synchronizer that is used to sync a scope as it detects the start and stop condition on the bus. I haven't used the circuit but it seems like a neat design and a great idea. At least the scope trace will line up with the start condition. After 3 different attempts to attach the schematic, I have given up. If you need it, send me an email off-list and I will attach it to a Reply. My email address is: rstofer "AT" pacbell "DOT" net Richard |
From: Richard T. S. <rs...@pa...> - 2008-08-12 02:35:39
|
kuntushi wrote: > Thanks for the info Richard. I don't think I'll need the analyser though, > the CRO I have here does I2C analysing on it and I can see the clock and > data lines nicely. > > It definitely seems that my camera chip isn't pulling the data line low. It > seems like the gumstix is always asserting on that line though, so I'm > wondering if maybe my pull ups aren't right or something like that. > Assuming that the camera chip is working and there is a connection between > the SDA and SCL lines, can anyone think of any other reason the slave > wouldn't pull the data line low? Or even suggestions for trying to fix it. > I'll try some higher pull ups and some other stuff now, but any other ideas > would be greatly appreciated. > > I commonly see the pull-up resistors around 2.2k. The I2C specification has a formula for calculating them but for 100k the values tend to be in the 1.8 to 2.2k range. Make certain there is a common ground between the camera power supply and the Verdex supply. No worry if they are the same supply. Recheck the address thing. Some suppliers calculate their addresses based on only the 7 bits (say 40h) and figure the users will double it to 80h for write and add one to get 81h for reading. Other vendors calculate the address as 80h or 81h as though it was actually an 8 bit address. They may, or may not, tell you about adding 1 to read. If you aren't getting the ACK, the camera isn't seeing a valid address. It's pretty much as simple as that. The remainder of the transaction may not work but at least for first ACK should come along simply as acknowledging that there is a device at that address. Richard |
From: kuntushi <kun...@ya...> - 2008-08-12 02:55:14
|
rtstofer wrote: > > kuntushi wrote: >> Thanks for the info Richard. I don't think I'll need the analyser >> though, >> the CRO I have here does I2C analysing on it and I can see the clock and >> data lines nicely. >> >> It definitely seems that my camera chip isn't pulling the data line low. >> It >> seems like the gumstix is always asserting on that line though, so I'm >> wondering if maybe my pull ups aren't right or something like that. >> Assuming that the camera chip is working and there is a connection >> between >> the SDA and SCL lines, can anyone think of any other reason the slave >> wouldn't pull the data line low? Or even suggestions for trying to fix >> it. >> I'll try some higher pull ups and some other stuff now, but any other >> ideas >> would be greatly appreciated. >> >> > I commonly see the pull-up resistors around 2.2k. The I2C specification > has a formula for calculating them but for 100k the values tend to be in > the 1.8 to 2.2k range. > > Make certain there is a common ground between the camera power supply > and the Verdex supply. No worry if they are the same supply. > > Recheck the address thing. Some suppliers calculate their addresses > based on only the 7 bits (say 40h) and figure the users will double it > to 80h for write and add one to get 81h for reading. > > Other vendors calculate the address as 80h or 81h as though it was > actually an 8 bit address. They may, or may not, tell you about adding > 1 to read. > > If you aren't getting the ACK, the camera isn't seeing a valid address. > It's pretty much as simple as that. The remainder of the transaction > may not work but at least for first ACK should come along simply as > acknowledging that there is a device at that address. > > Richard > I've tried basically all addresses. It does list it as 0x42 for write, 0x43 for read, so I'm basically certain its address is 0x21. I've tried basically every address from 0x01 to 0x4F with no luck. The power supplies are different, but the grounds are all connected, so that's not the issue either unfortunately. I'll try with different resistors, hopefully one of them will work. If not, I guess it's just my chip not working, which would be a major drag. -- View this message in context: http://www.nabble.com/I2C-Setup-for-Verdex-tp18807158p18937274.html Sent from the Gumstix mailing list archive at Nabble.com. |