I2c Read/Write on EEprom not proper

Hello all,
I tried in different way to write on EEprom.
The EEPROM has 16 Byte addressing (24LC64)

It gave me always the same results, no error, ff when I read.
I used the i2c-tools, a simple SysFS write read and a c program. I saw the generic driver too(when I enabled it I check that was used with i2c-detect -y 1), but so far nothing works at expected.
No error, but when I read it I always got 0xff.

root@b2qt-colibri-imx7-emmc:~# date | strace eeprog -f -16 -w 0 /dev/i2c-1 0x50
execve("/usr/sbin/eeprog", ["eeprog", "-f", "-16", "-w", "0", "/dev/i2c-1", "0x50"], 0x7eddfd38 /* 17 vars */) = 0
brk(NULL)                               = 0xa78000
uname({sysname="Linux", nodename="b2qt-colibri-imx7-emmc", ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f73000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=24257, ...}) = 0
mmap2(NULL, 24257, PROT_READ, MAP_PRIVATE, 3, 0) = 0x76f6d000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libi2c.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\6\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=5312, ...}) = 0
mmap2(NULL, 69640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x76f3c000
mprotect(0x76f3d000, 61440, PROT_NONE)  = 0
mmap2(0x76f4c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x76f4c000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\271u\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=923264, ...}) = 0
mmap2(NULL, 992036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x76e49000
mprotect(0x76f26000, 65536, PROT_NONE)  = 0
mmap2(0x76f36000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xdd000) = 0x76f36000
mmap2(0x76f39000, 8996, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x76f39000
close(3)                                = 0
set_tls(0x76f73ff0)                     = 0
mprotect(0x76f36000, 8192, PROT_READ)   = 0
mprotect(0x76f4c000, 4096, PROT_READ)   = 0
mprotect(0x4bb000, 4096, PROT_READ)     = 0
mprotect(0x76f75000, 4096, PROT_READ)   = 0
munmap(0x76f6d000, 24257)               = 0
write(2, "eeprog 0.7.5, a 24Cxx EEPROM rea"..., 43eeprog 0.7.5, a 24Cxx EEPROM reader/writer
) = 43
write(2, "Copyright (c) 2003 by Stefano Ba"..., 61Copyright (c) 2003 by Stefano Barbato - All rights reserved.
) = 61
write(2, "  Bus: /dev/i2c-1, Address: 0x50"..., 46  Bus: /dev/i2c-1, Address: 0x50, Mode: 16bit
) = 46
openat(AT_FDCWD, "/dev/i2c-1", O_RDWR)  = 3
ioctl(3, _IOC(0, 0x7, 0x5, 0), 0x7ecb0ae8) = 0
ioctl(3, _IOC(0, 0x7, 0x3, 0), 0x50)    = 0
write(2, "  Writing stdin starting at addr"..., 40  Writing stdin starting at address 0x0
) = 40
fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
brk(NULL)                               = 0xa78000
brk(0xa99000)                           = 0xa99000
read(0, "Thu Feb 20 15:53:14 UTC 2020\n", 4096) = 29
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
write(2, ".", 1.)                        = 1
ioctl(3, _IOC(0, 0x7, 0x20, 0), 0x7ecb0a80) = 0
nanosleep({tv_sec=0, tv_nsec=5000000}, NULL) = 0
read(0, "", 4096)                       = 0
write(2, "\n\n", 2

)                     = 2
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

This is an example, but I tried with the c program in attachment an when I read I have only garbage.

Dear @andreat

I think you shouldn’t use read/write to access the i2c device. You should always use ioctl with I2C_RDWR even for reading and writing. An example can be found here:
https://github.com/eichenberger/i2ctool/blob/master/main.c
or here:
https://github.com/MatteoRagni/i2c-tools/blob/master/eepromer/eeprom.c

Regards,
Stefan

Thank you Stefan for quick reply.
I downloaded your GitHub and cross-compiled it, but i think i need a simple example
I tried:

root@b2qt-colibri-imx7-emmc:~# ./i2ctool -d /dev/i2c-1 -a 0x50 -w 0x00,0x01,0x02
root@b2qt-colibri-imx7-emmc:~# ./i2ctool -d /dev/i2c-1 -a 0x50 -r 10
Received data from slave 0x50:
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
root@b2qt-colibri-imx7-emmc:~# ./i2ctool -d /dev/i2c-1 -a 0x50 -w 0,1,2
root@b2qt-colibri-imx7-emmc:~# ./i2ctool -d /dev/i2c-1 -a 0x50 -r 10
Received data from slave 0x50:
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

Hi @andreat

Can you once do a scan with:

./i2ctool -d /dev/i2c-1 -c

Do you maybe have the possibility to measure the signals with an oscilloscope? It would be interesting to see if the device really sends 0xFF or if the signal just stays high which would mean the device basically just doesn’t react on the address (which gives 0xFF).

Regards,
Stefan

Hi @stefan.tx

./i2ctool -d /dev/i2c-1 -c
Check address:
0x7E
Found devices at addresses:
0x18 0x50

Do you maybe have the possibility to measure the signals with an oscilloscope?
We had same idea, but so far we cannot use an oscilloscope


But did you check on your side on an Eeprom?
Is it writing every time all the Eeprom?
How does it work and which setup did you use?

I would suggest for you trying the regular EEPROM driver:

http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/misc/eeprom/Kconfig?h=toradex_4.14-2.0.x-imx#n3

I successfully used this one before but can’t remember on-top-of-my-head now whether this was with an 8-bit or 16-bit addressed device. However, the driver clearly also supports 16-bit devices:

http://git.toradex.com/cgit/linux-toradex.git/tree/Documentation/devicetree/bindings/eeprom/at25.txt?h=toradex_4.14-2.0.x-imx#n9

Ok, we are investigating and every suggestion is welcome.

With that It really should just workTM.

Thank you.
I mean as I reported at the beginning, we already used this approach, but we are going to understand possible hardware settings(already measure with an oscilloscope, signal was ok) and not only possible not proper software use.

Hi

Is the issue present on one sample of EEPROM or did you try different samples?

Best regards,
Jaski

Hi,

Thanks for the question.
We tested on two different samples to avoid to get a trivial hardware issue.

Hi

You are welcome.

It is not easy to help you without having the schematic of your board. Just a question, did you correctly set the Write protection Pin for the EEPROM?

This is the output from the Datasheet.

“Write-Protect (WP)This pin must be connected to either VSS or VCC. If tiedto VSS, write operations are enabled. If tied to VCC, write operations are inhibited but read operations are not affected”.

Best regards,
Jaski