I2C: OMAP: spurious i2c probe addresses
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.
Here's the behavior I see:
--------------------------
# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C
Here's what it looks like after reverting the commit:
------------------------------------------
# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Quoted 35 lines · Michael Jones
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit
0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.Here's the behavior I see:
--------------------------# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6CHere's what it looks like after reverting the commit:
------------------------------------------# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51
Quoted 1 line
-Michael
Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve i2c_probe() as well.
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Hello Michael,
Quoted 36 lines · Michael Jones
Quoted 35 lines · Michael Jones
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit
0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.Here's the behavior I see:
--------------------------# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6CHere's what it looks like after reverting the commit:
------------------------------------------# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51
Quoted 8 lines
Quoted 1 line
-Michael
Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve
i2c_probe()as well.
Ah, good point. Thanks! (I just looked at this commit, and couldn;t find, why it does such a mess) ... waiting for a patch, which adds 2-byte subaddress support ;-)
bye,
Heiko
Signature · 2 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Michael,
Quoted 36 lines · Michael Jones
Quoted 35 lines
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit
0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.Here's the behavior I see:
--------------------------# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6CHere's what it looks like after reverting the commit:
------------------------------------------# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51
Quoted 7 lines
Quoted 1 line
-Michael
Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve
i2c_probe()as well.
Using CONFIG_SYS_I2C_NOPROBES for the extended adressing devices should do the trick.
Regards,
Andr?
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Quoted 38 lines · Michael Jones
Quoted 35 lines · Michael Jones
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit
0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.Here's the behavior I see:
--------------------------# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6CHere's what it looks like after reverting the commit:
------------------------------------------# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51Quoted 1 line
-Michael
Quoted 8 lines
Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve
i2c_probe()as well.-Michael
Hi Michael,
What do you mean by sub-address? The address within the device or an extended chip address?
The change I made aborts the write after sending the 7 bit chip address and 1 write bit, so a device's internal address shouldn't be relevant.
Extended chip addressing devices would not be supported as it stands. I can imagine NACK may not be occur for a device waiting for more chip address bits, though I would have thought it wouldn't drive the bus low until the full address is received.
Can you tell us what device this is? Even better a link to the data sheet.
Does your bus have only one master (the OMAP)? There could be an issue if bus arbitration failures occur.
I guess your bus pull-ups are strong enough to assert the NAK...? If not, you probably you would have seen other issues before now.
Nick.
Quoted 39 lines · Nick Thompson
Quoted 38 lines · Michael Jones
Quoted 36 lines · Michael Jones
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit
0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.Here's the behavior I see:
--------------------------# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6CHere's what it looks like after reverting the commit:
------------------------------------------# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51-Michael
Quoted 9 lines
Quoted 8 lines
Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve
i2c_probe()as well.-Michael
Hi Nick,
Quoted 4 lines
Hi Michael,
What do you mean by sub-address? The address within the device or an extended chip address?
I mean the address within the device.
Quoted 4 lines
The change I made aborts the write after sending the 7 bit chip address and 1 write bit, so a device's internal address shouldn't be relevant.
Mmm, OK. I only jumped to that conclusion because your comment in the commit message mentions that the driver only supports devices with single-byte subaddresses.
Quoted 5 lines
Extended chip addressing devices would not be supported as it stands. I can imagine NACK may not be occur for a device waiting for more chip address bits, though I would have thought it wouldn't drive the bus low until the full address is received.
Curious. It sounds like you would've expected it to work with my device.
Quoted 3 lines
Can you tell us what device this is? Even better a link to the data sheet.
It's a 128 Kbit EEPROM.
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00259167.pdf
Quoted 3 lines
Does your bus have only one master (the OMAP)? There could be an issue if bus arbitration failures occur.
OMAP is the only master.
Quoted 3 lines
I guess your bus pull-ups are strong enough to assert the NAK...? If not, you probably you would have seen other issues before now.
Right- I assume this is not the problem because I haven't had other issues before now.
Quoted 2 lines
Nick.
I am going to focus on getting proper reads and writes working with my device before looking into this myself. If you have suggestions in the meantime, I'm all ears. Otherwise I'll be in touch when I get around to looking at probe again.
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Quoted 60 lines · Michael Jones
Quoted 39 lines · Nick Thompson
Quoted 38 lines · Michael Jones
Quoted 36 lines · Michael Jones
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit
0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices.Here's the behavior I see:
--------------------------# i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6CHere's what it looks like after reverting the commit:
------------------------------------------# i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51-Michael
Quoted 9 lines
Quoted 8 lines
Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve
i2c_probe()as well.-Michael
Hi Nick,
Quoted 4 lines
Hi Michael,
What do you mean by sub-address? The address within the device or an extended chip address?
I mean the address within the device.
Quoted 1 line
Quoted 7 lines
Quoted 3 lines
The change I made aborts the write after sending the 7 bit chip address and 1 write bit, so a device's internal address shouldn't be relevant.
Mmm, OK. I only jumped to that conclusion because your comment in the commit message mentions that the driver only supports devices with single-byte subaddresses.
That appears to true. The Davinci driver supports two byte addresses. You might be able to use that as a template for your changes.
Quoted 8 lines
Quoted 6 lines
Extended chip addressing devices would not be supported as it stands. I can imagine NACK may not be occur for a device waiting for more chip address bits, though I would have thought it wouldn't drive the bus low until the full address is received.
Curious. It sounds like you would've expected it to work with my device.
Yes.
I've made a similar change to Davinci's probe and it works with a 25x256 (Spansion) device (and more stubborn Analog Devices DACs and ADCs, as well as temperature and current sensors). The probe always returns the same results, much like our OMAP boards.
Quoted 5 lines
Quoted 4 lines
Can you tell us what device this is? Even better a link to the data sheet.
Quoted 8 lines
It's a 128 Kbit EEPROM.
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00259167.pdfQuoted 3 lines
Does your bus have only one master (the OMAP)? There could be an issue if bus arbitration failures occur.
OMAP is the only master.
Okay.
Quoted 7 lines
Quoted 4 lines
I guess your bus pull-ups are strong enough to assert the NAK...? If not, you probably you would have seen other issues before now.
Right- I assume this is not the problem because I haven't had other issues before now.
Hmm, I'm a bit stumped then. I'm still playing with I2C on Davinci, so more ideas may come out of that.
The bus pull-ups on our boards are 2k-ohm to 3v3 rail, if it helps.
Quoted 8 lines
Quoted 3 lines
Nick.
I am going to focus on getting proper reads and writes working with my device before looking into this myself. If you have suggestions in the meantime, I'm all ears. Otherwise I'll be in touch when I get around to looking at probe again.
Okay, let me know how you get on.
Quoted 2 lines
-Michael
Nick.