I have now been able to write to the eeprom.
First I wrote a file with 30 bytes of data, then I calculated the crc16
(pol 8005) and inverted the result bit wise.
int main(void)
{
uint8_t buf[32];
uint16_t crc;
std::ofstream out_file;
crc = 0;
for (int idx = 0; idx < 30; idx++)
{
buf[idx] = idx + 49; // fill buffer with data
crc = crc16_byte_8005(crc, buf[idx]);
}
buf[30] = ~((uint8_t)((crc & 0x00FF)));
buf[31] = ~((uint8_t)((crc & 0xFF00) >> 8));
out_file.open ("/home/debian/test/c_file");
if(out_file.is_open())
{
out_file.write((char *)(&buf), 32);
out_file.close();
}
return 0;
}
The final file I could both write and read to eeprom.
debian@beaglebone:~/test$ cat c_file >
/sys/bus/w1/devices/23-000002eddd9b/eeprom
debian@beaglebone:~/test$ cat /sys/bus/w1/devices/23-000002eddd9b/eeprom |
hexdump
0000000 3231 3433 3635 3837 3a39 3c3b 3e3d 403f
0000010 4241 4443 4645 4847 4a49 4c4b 4e4d 63ba
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200
So to use the eeprom without crc on every page the driver needs to be
re-compiled with other options.
onsdag 30 september 2020 kl. 14:40:40 UTC+2 skrev Johan Lind:
> I think we're getting closer to the truth now.
>
> Reading the source code and especially this section is interesting:
> #ifdef CONFIG_W1_SLAVE_DS2433_CRC
> <http://sbexr.rabexc.org/latest/sources/0f/5e84f0288ea608.html#00b1600900b16024>
>
> /* can only write full blocks in cached mode */
> if ((off
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cd008000cd00f>
>
> & W1_PAGE_MASK
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001f0090001f017>)
>
> || (count
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cd014000cd01b>
>
> & W1_PAGE_MASK
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001f0090001f017>))
>
> {
> dev_err
> <http://sbexr.rabexc.org/latest/sources/1c/d25b2fb3f904be.html#000670090006802b>(&sl->dev,
>
> "invalid offset/count off=%d cnt=%zd\n", (int)off, count);
> return -EINVAL
> <http://sbexr.rabexc.org/latest/sources/7f/c1319580667ad5.html#0001a0090001a011>;
>
> }
> /* make sure the block CRCs are valid */
> for (idx
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011>
>
> = 0; idx
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011>
>
> < count
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cd014000cd01b>;
>
> idx
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011>
>
> += W1_PAGE_SIZE
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001d0090001d017>)
>
> {
> if (crc16
> <http://sbexr.rabexc.org/latest/sources/0d/c2946195028c93.html#0001400100014037>
> (CRC16_INIT
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001200900012015>,
>
> &buf
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cc028000cc02e>
> [idx
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011>],
>
> W1_PAGE_SIZE
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001d0090001d017>)
>
> != CRC16_VALID
> <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001300900013016>)
>
> {
> dev_err
> <http://sbexr.rabexc.org/latest/sources/1c/d25b2fb3f904be.html#000670090006802b>(&sl->dev,
>
> "bad CRC at offset %d\n", (int)off);
> return -EINVAL
> <http://sbexr.rabexc.org/latest/sources/7f/c1319580667ad5.html#0001a0090001a011>
> ;
> } }
>
> If I try to run these commands:
> echo "12345678901234567890123456789012" >
> /sys/bus/w1/devices/23-000002eddd9b/eeprom
> echo "1234567890123456789012345678901" >
> /sys/bus/w1/devices/23-000002eddd9b/eeprom
> dmesg | tail
> [80808.027040] w1_slave_driver 23-000002eddd9b: invalid offset/count off=0
> cnt=33
> [80829.659168] w1_slave_driver 23-000002eddd9b: bad CRC at offset 0
>
> I removed some output from my terminal and focused on these lines.
> The errors found using dmesg looks to come from this section in the
> driver. If I send 33 bytes I get the invalid offset/count error and with 32
> bytes I pass this section and get crc error.
> Now I have to try to manually calculating the crc and see where it takes
> me.
>
> onsdag 30 september 2020 kl. 13:16:09 UTC+2 skrev Sven Norinder:
>
>> Maybe kernel must have crc enabled for 2433 writes?
>> Last line implies something about writes.
>>
>> config W1_SLAVE_DS2433
>> tristate "4kb EEPROM family support (DS2433)"
>> help
>> Say Y here if you want to use a 1-wire
>> 4kb EEPROM family device (DS2433).
>>
>> config W1_SLAVE_DS2433_CRC
>> bool "Protect DS2433 data with a CRC16"
>> depends on W1_SLAVE_DS2433
>> select CRC16
>> help
>> Say Y here to protect DS2433 data with a CRC16.
>> Each block has 30 bytes of data and a two byte CRC16.
>> Full block writes are only allowed if the CRC is valid.
>>
>> /Sven
>>
>> onsdag 30 september 2020 kl. 10:56:55 UTC+2 skrev Johan Lind:
>>
>>> Well, I have an i2c memory on the same board and to read and write to
>>> that I can use the following commands:
>>> write
>>> cat data.eeprom > /sys/bus/i2c/devices/2-0057/eeprom
>>> read
>>> cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump
>>>
>>> I did try your suggestion of using dd but I could not get it to work.
>>> root@beaglebone:/home/debian# dd if=/dev/zero
>>> of=/sys/bus/w1/devices/23-000002eddd9b/eeprom bs=32
>>> dd: error writing '/sys/bus/w1/devices/23-000002eddd9b/eeprom': Invalid
>>> argument
>>> 1+0 records in
>>> 0+0 records out
>>> 0 bytes copied, 0.0159578 s, 0.0 kB/s
>>> root@beaglebone:/home/debian#
>>>
>>> As the eeprom is written to contain data on another device, so I thought
>>> it would be enough to use /dev/zero as input.
>>> Reading out data show no change of content (as expected consider the
>>> output from dd)
>>> cat /sys/bus/w1/devices/23-000002eddd9b/eeprom | hexdump
>>> 0000000 00ff 55aa 00ff 55aa 00ff 55aa 00ff 55aa
>>> onsdag 30 september 2020 kl. 07:15:53 UTC+2 skrev Sven Norinder:
>>>
>>>> The eeprom probably is a device, not a filesystem.
>>>> Use dd instead.
>>>> /Sven
>>>>
>>>> tisdag 29 september 2020 kl. 17:59:14 UTC+2 skrev Johan Lind:
>>>>
>>>>> I tried with only a short (6 bytes) string but still the same
>>>>> behaviour.
>>>>>
>>>>>
>>>>> tisdag 29 september 2020 kl. 17:45:47 UTC+2 skrev
>>>>> [email protected]:
>>>>>
>>>>>> I suggest trying to write less than 32 bytes (the dmesg implies
>>>>>> something wrong with offset or count) -- create a file of less than 32
>>>>>> bytes and copy to eeprom
>>>>>> cd ~
>>>>>> echo "1234567890" > file10
>>>>>> cp -T file10 /sys/bus/w1/devices/23-000002eddd9b/eeprom
>>>>>>
>>>>>> In the data sheet you need a much smaller R[PU] to write than read
>>>>>> https://datasheets.maximintegrated.com/en/ds/DS2433.pdf
>>>>>>
>>>>>> On Tuesday, 29 September 2020 at 16:03:48 UTC+1 RobertCNelson wrote:
>>>>>>
>>>>>>> On Tue, Sep 29, 2020 at 9:55 AM 'Johan Lind' via BeagleBoard
>>>>>>> <[email protected]> wrote:
>>>>>>> >
>>>>>>> > Yes, it does still show eeprom
>>>>>>> >
>>>>>>> > debian@beaglebone:~$ ls /sys/bus/w1/devices/23-000002eddd9b
>>>>>>> > driver eeprom id name power subsystem uevent
>>>>>>> > debian@beaglebone:~$ ls /sys/bus/w1/devices/
>>>>>>> > 23-000002eddd9b w1_bus_master1
>>>>>>> > debian@beaglebone:~$
>>>>>>> > debian@beaglebone:~$ ls -al /sys/bus/w1/devices/23-000002eddd9b/
>>>>>>> > total 0
>>>>>>> > drwxrwxr-x 3 root gpio 0 Sep 29 14:00 .
>>>>>>> > drwxrwxr-x 4 root gpio 0 Sep 29 14:00 ..
>>>>>>> > lrwxrwxrwx 1 root gpio 0 Sep 29 14:00 driver ->
>>>>>>> ../../../bus/w1/drivers/w1_slave_driver
>>>>>>> > -rw-rw-r-- 1 root gpio 512 Sep 29 14:07 eeprom
>>>>>>>
>>>>>>> Side note, you don't' have to be root, the "gpio" group is the
>>>>>>> default
>>>>>>> for debian..
>>>>>>>
>>>>>>> > -r--r--r-- 1 root gpio 4096 Sep 29 14:00 id
>>>>>>> > -r--r--r-- 1 root gpio 4096 Sep 29 14:00 name
>>>>>>> > drwxrwxr-x 2 root gpio 0 Sep 29 14:00 power
>>>>>>> > lrwxrwxrwx 1 root gpio 0 Sep 29 14:00 subsystem -> ../../../bus/w1
>>>>>>> > -rw-rw-r-- 1 root gpio 4096 Sep 29 14:00 uevent
>>>>>>> > debian@beaglebone:~$
>>>>>>>
>>>>>>> not sure why you can't write...
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> --
>>>>>>> Robert Nelson
>>>>>>> https://rcn-ee.com/
>>>>>>>
>>>>>>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/76cf8892-1929-470f-928a-be972e52742bn%40googlegroups.com.
