2024-12-10 - m24c02 EEPROM rant

simple thing – while working on YALS i needed EEPROM to store some persistent values (e.g. servo travel limits, LED brightness, etc.). i recently mentioned that whole project is working nice, except for EEPROM. after ~2 days wasted i finally managed to locate the problem.

since i literally need just ~20B i opted for m24c02 EEPROM. it's cheap, common and has 256B for data, which is even more than i need. cool.

for reference – here's the chip layout:

i got my chips from reputable source, for a stock price. i have no reasons to believe i have a knock-off that is just faulty.

after soldering 1st prototype it turned out that the chip's datasheet has MANY issues. let's go through them 1-by-1 in this section.

the chip looks like this…

noticed sth? or rather – noticed sth missing? yes – there's not direction marking! all the chips i've worked with so far have either “up mark” like this:

or 1st pin is marked like this:

m24c02 from ST has neither of these, so go figure…

datasheet does mention where's the “pin 1”… however there's no marking that would allow you to orient the chip correctly. so it's still 50/50.

…in case you wonder – this is where 1st pin is:

you can use logo and text as a reference for orientation. this seems to work at least for my batch. i hope this is generally true.

btw: i have a gut feeling i'll be coming back to this post myself quite a few times to double-check my memory…

first interesting thing is addressing. datasheet is clear about it:

for the sake of discussion let's assume all Ex pins are driven low. so addresses should be:

• 0xA0 for reading
• 0xA1 for writing

well – nothing further from the truth! actual address is 0x50 for both reads and writes. notice the pattern? A is binary 1010 and 5 is binary 0101 - all bits are shifted by 1.

more over – it's the same address for both read and write. datasheet is bluntly wrong about that. funny enough – the internet seems to get it right, as ~everywhere i've looked, it mentions 0x50 (aka: correct) I2C address.

first 2 problems i've managed to solved reasonably fast. this one however is what took ~95% of the 2 days mentioned at the beginning, including a custom rig for testing chips outside of the circuit. SMD is “fun” in this respect, as it obviously does not match the breadboard. oh well…

there's a !WC pin, for enabling / disabling writing to EEPROM. as per docs, in order to write, the pin has to be driven low. since in my design i did not care about that, i just drove it low. exactly the same way as Ex pins for addressing. addressing worked. it took me nearly 2 days to figure out that for write-protection pin it did not!

the nice part is that chip is using I2C, so one can clearly see if the other end does not respond. in that case ACK bits are not sent, and thus error is returned from I2C library. my problem was that i got all the ACKs i needed for reading. but when i started to try to write, the chip seemed to… crash? after 1st (address) byte ACKed, it just seize to respond to any other requests – including previously working read requests.

the breakthrough came from the test rig, where after some time, as an experiment, i've decided to drive !WC high – just to see what happens (perhaps this is also wrong in the docs?). turned out that now i started to get error replies for write requests! ok – that's a progress. chip is still usable for reading. there was clearly sth wrong with write-enable pin, then. i could pull it high, bit pulling it low did not seem to work. pulling it low via ~2k, ~5k, or 10k resistors sometimes made it work, but it was not reliable.

turned out that the “correct answer” was to keep pin floating. while in docs this is one of the supported options:

…in practice it seemed to be the only one that actually worked! i'm not a huge fan of leaving any pins floating, as in high EM noise environment it can act like an antenna, picking up noise for all over the place. however here it seems to be the only option.

my soul is crying, but i cannot argue with reality – the pin must be left floating, for some reason. i was contemplating connecting !WC to µC's pin in the next iteration. however after this experience i think i've lost interest in experimenting with this chip and will likely settle onto sth that appears to be working.

i'm disappointed. end of rant. hope this will be helpful for you, in case you bump into the same issue(s) that i did.