Hi,
We want to test I2C in beaglebone black board using external EEPROM CAT24C128WI-G .
It is connected to I2C-2 and detecting the device address as 0x51 and we are trying to write to the EEPROM address and read it back using the following commands.
i2cset -y 2 0x51 0x0001 0x11 w
i2cget -y 2 0x51 0x0001 w
However it is always responding with 0xff
Please let us know the steps to solve this issue.
Thanks,
Devika R
How is the WP pin wired on the eeprom ? Could the write protect be enabled ?
Hi,
WP is left open, write protect is not enabled
Thanks,
Devika R
As you are not getting an error, I would guess you are talking with the eeprom.
As you are specifying a word write have to tried changing the 0x11 to 0x0011 ?
I wouldn’t expect it to mater, but it would depend on how i2cset parses the parameters.
You could also just try writing a byte rather than a word.
Hi,
We have tried by writing as a byte, but still it has same issue.
Also we have tried by changing 0x11 to 0x0011 , However it is still responding as 0xffff.
debian@beaglebone:~$ i2cdetect -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – – – –
50: – 51 – – UU UU UU UU – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –
debian@beaglebone:~$ i2cset -y 2 0x51 0x0001 0x0011 w
debian@beaglebone:~$ i2cdetect -y -r 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – – – – – – – – –
50: – 51 – – UU UU UU UU – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –
debian@beaglebone:~$ i2cget -y 2 0x51 0x0001 w
0xffff
debian@beaglebone:~$
Thanks,
Devika R
Hi, @Devika, were you able to solve your issue with the CAT24 EEPROM? I would also appreciate guidance from anyone else!
My team is using a similar chip (CAT24C16xxxx) with a BeagleBone Green. But we are having an issue on bootup where the pins are not successfully initialized, with errors such as
debian@beaglebone:~ $ config-pin P8.34 hi
P8_34 pinmux file not found!
Pin has no cape: P8_34
(We are still on an old debian 9 image and in the process of upgrading the OS, so please pardon the “old” config-pin command)
When we remove the EEPROM chip from the I2C bus, the BBG is able to boot up and initialize pins without issue.
NOTE: eMMC is wiped with sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024, booting off SD card
U-boot log when booting fails to initialize pins in text file, along with version output:
bbg1_deb9_stock_uboot_log_dcpower.txt (2.8 KB)
bbg1_deb9_stock_version_output_dcpower.txt (1.3 KB)
what does gpioinfo have for P8_34?
Hi, @amf99, thanks for your reply.
I was able to resolve this issue. I realized that the CAT24C16xxxx chip can only ever be addressed at I2C address 0x50, and that it is impossible to change it on this particular model. It happens to be the same address as the BeagleBone’s internal EEPROM. I believe this was somehow causing a conflict as the BB booted up, even though the internal EEPROM on the BB and the external CAT24C16 EEPROM we were using were on two different I2C buses (0 vs 2).
This was perhaps further confirmed by the u-boot log message—which you can see in bbg1_deb9_stock_uboot_log_dcpower.txt above—whenever the external CAT24C16 EEPROM was connected:
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Normally, without the external EEPROM connected, the config-pin command above would have worked without errors as I had a service that automatically ran and exported/setup that pin. I suspect the error immediately above caused that service not to run and/or caused the loading of uEnv.txt to fail, meaning it didn’t load the universal cape, etc. In fact, there’s only a single line mentioning uboot_overlays; I would expect to see more under normal circumstances.
We replaced the CAT24C16 chip with a CAT24C32 instead, and hardwired its I2C address to 0x54, the first cape address (we use no other capes but our custom-made one). Booting the BB afterwards, the EEPROM error did not appear, and the config-pin command ran without an error.
So to anyone experiencing similar issues with an external EEPROM, I suggest taking a look at your u-boot logs for lines mentioning “eeprom.”
Sounds really odd that two different busses should interfere with one another.
One thing to keep in mind is that u-boot and Linux might map things differently.
If you were to say, wire in SDA only once Linux has started, are the two EEPROMs
still on “the same” bus or does something change?
Just out of curiosity, what SCL/SDA pin pair are you using exactly?
For the external EEPROM, we’re using P9_18 P9_20 and P9_19.
That can’t be right!
According to my schematic here, you’re straddling I2C1 and I2C2 with that config…
It’s not! 
I mistyped. I meant to say P9_19 and P9_20. Does a fresh U-boot on a newly flashed SD card with BeagleBone Black’s official Debian 12.2 image use these pins at all in order to find the onboard EEPROM?
There’s definately still some weirdness going on, because even if you did put
an EEPROM at 0x50, there’s just no way it could interfere with the internal one,
as that is on I2C0 and you’re on I2C2.
I don’t even think you could connect the two busses by accidently pin-muxing them.
There’s a Gremlin hiding somewhere, I just don’t see where.
You did pull up I2C2 as there are no pullups on the board to my knowledge?
Hey… @bibg ,
I think the localized, onboard I2C pins are 19 and 20. Try another set of I2C pins on your board.
Seth
P.S. You can find what is mapped to what with ls -la at your local I2C file.
So say, i2c2 is located at /dev/bone/i2c/2, just use the command ls -la. Also, I think config-pin is no more unless you or others have been using it for other reasons. I say that because I have an older board with an older kernel and image that used config-pin. The newer images are set in “stone.” I have found that many files are located in /dev/bone/ or not at all. There were some GPIO pins available still but as input. One would just need to make them output to use them.
