Sebastien Lorquet email@example.com [nuttx]
2018-02-12 16:22:53 UTC
Now that I have received PCBs and NuttX is running on my new hn70ap board, I am
trying to bring up its i2c eeprom.
First, I see that NuttX still does not have an i2c eeprom driver.
The only code I see is a mtd driver that attempts to do things with at24
eeproms, but this is severely unsuitable for direct and simple EEPROM use. So
I'm writing a i2c eeprom driver that directly maps the memory contents to
/dev/eeprom the same way that it's done for 25xx SPI eeproms.
However, it did not work as expected.
The I2C application is able to read the memory. I know that it works, because my
memory is a 24AA02E48 that contains a MAC address in its last 6 bytes. It can be
read via the built-in i2c tool:
nsh> i2c get -b 3 -a 50 -r fa -i 6
nsh: i2c: too many arguments
READ Bus: 3 Addr: 50 Subaddr: fa Value: d8
READ Bus: 3 Addr: 50 Subaddr: fb Value: 80
READ Bus: 3 Addr: 50 Subaddr: fc Value: 39
READ Bus: 3 Addr: 50 Subaddr: fd Value: 9c
READ Bus: 3 Addr: 50 Subaddr: fe Value: 0c
READ Bus: 3 Addr: 50 Subaddr: ff Value: 0d
D88039 is a registered MAC prefix for Microchip, so I belieeve the memory is
powered and readable.
But it does not via hexdump! Sometimes I get a bunch of FFs, sometimes I get
Maybe I am still being hit by the stm32 i2c problems.
One of the things that is clear, is that the stm32 drivers are quire old, since
they do not support I2C_M_NORESTART. I discovered that far more code related to
this feature is present in the stm32l4 and stm32f7 drivers than in the stm32
ones. The Release Notes tell me that Jussi Kivilinna did extensive work on this
feature for both stm32f7 and stm32l4.
I would be grateful if you could do the same for stm32f4. I am obviously ready
to test the changes.
Polled mode does not help. Alternate driver does not help.
So I have added kludges in the driver to:
-read the array byte per byte, it works the sameÂ correct way as the i2c tool.
Can we deduce that the stm32 i2c driver is not working when buffers are bigger
than one byte?
-write the memory using a single i2c message and a temporary buffer to hold both
the subaddress and the data.
It does not work yet. So no conclusion yet.
I am reluctant to do the write byte per byte since it possibly wears the memory
faster than page per page, but I will test that asap.