Architecture / Interface

[yoh-there]

Pardon the narrative....

Ever since the earliest versions of SavvyCan / GVRET I had a problem with a non working EEPROM. I was very aware this had to do with my own hardware setup (just a Due with a tranceiver). Sequence of events basically being:

• not aware that the SAM didn't van EEPROM (D'uh) --> buy EEPROM PCB on eBay
• install EEPROM on I2C. Didn't work in GVRET.
• tried simple test routines, didn't work (no native EEPROM in library D'Uh)
• tried Wire_EEPROM with example code. Didn't work. Many tries, trow-in-corners, pick up again and hours down the line I decided something hardware must have been broken and basically gave up. Setting bus speeds at fire-up was OK, occasional use anyway.

This weej (about a year or more later that is), I was modifying the hardware a little, checked with a scope and could see there was traffic on the I2C bus. Decided I should give it one more shot, I downloaded another Due I2C EEPROM piece of code and it worked, WTF?

Then dug into the spec sheets and the code to find what should have been obvious:

• Wire_EEPROM addresses 256 byte pages, not bytes. As GVRET uses page 275, this had never sunk in; it appeared to be a very valid byte address
• CANDUE uses a 2Mbit Atmel EEPROM. My PCB was a 256kbit AT24C32. This caused several collisions:
• • page 275 does not exist in the 256kbit (goes to 127)
• • worse, the 256kbit EEPROM can only write 64 byte pages at once. After that the write pointer overflows in the same 64 byte page, destroying the data

Made a dirty update in this code to emulate the 256 byte page writes, set page in GVRET to 0 and now it works.

Conclusions / wrap up:

• I hope this all gave you a good chuckle. ;-)
• Read, don't assume (me that is). On chips used, on interface

Still, if only to maybe save another poor sod the same trouble, may I kindly suggest to put something like this in the README.MD of Wire_EEPROM:

"This is an interface that reads/writes data structures of max 256 bytes to EEPROM based on 256 byte sized page numbers, not byte addresses. It assumes an AT24CM02 2MB EEPROM chip, capable of doing 256 byte single writes."

Thank you for all the hard work!

ps: of course this is not an Issue. Close at will

[collin80]

Yeah, the EEPROM routines are pretty custom engineered for the EEPROM chip we used. Also, the reason it uses such a high EEPROM address is that the GVRET firmware can run on a GEVCU (vehicle ECU) as well and that board uses the lower EEPROM for its configuration. By setting the config so high up in EEPROM I could run either firmware on the same board and they wouldn't zap each other's configuration. Also, I modified the I2C library to allow 256 byte writes to EEPROM because that's the page size of the EEPROM used and you always write 256 bytes anyway. By being able to blast out all the bytes at once you can write the whole page once and not have it constantly rewrite it as you save little pieces.

Anyway, it probably would be good to explain that the EEPROM routines are kind of custom and special and you shouldn't try to use them on anything other than the intended hardware without some serious thought about the consequences. The code will run on basically anything with a SAM3X but you do have to be careful about potential hardware issues. I'll try to document that as well as the other hardware issues like how the CAN bus transceiver is connected.