blog:2024:12:10:2024-12-10_-_m24c02_eeprom_rant [BaSzErr]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 2024-12-10 - m24c02 EEPROM rant ======

simple thing -- while working on [[https://github.com/el-bart/yals|YALS]] i needed [[wp>EEPROM]] to store some persistent values (e.g. servo travel limits, LED brightness, etc.). i recently mentioned that whole project is [[:blog:2024:11:24:2024-11-24_-_yet_another_linear_servo|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 [[http://www.st.com/resource/en/datasheet/m24c02-f.pdf|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:

{{:blog:2024:12:10:m24c02_pinout.png?400|m24c02 pinout}}


===== disclaimer =====

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.


===== problems =====

after soldering 1st prototype it turned out that the [[http://www.st.com/resource/en/datasheet/m24c02-f.pdf|chip's datasheet]] has MANY issues. let's go through them 1-by-1 in this section.


==== soldering ====

the chip looks like this...

{{:blog:2024:12:10:m24c02_photo.jpg?400|m24c02 photo}}

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:

{{:blog:2024:12:10:dip8_top_mark.jpg?200|dip8 top mark}}

or 1st pin is marked like this:

{{:blog:2024:12:10:dip8_pin_1_mark.jpg?200|dip8 1st pin mark}}

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.

{{:blog:2024:12:10:m24c02_packaging_note_for_s08n.png?600|m24c02 pseudo-marked pin 1 in the docs}}

...in case you wonder -- this is where 1st pin is:

{{:blog:2024:12:10:m24c02_pin_1_marked.jpg?400|m24c02 with 1st pin manually marked}}

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...


==== addressing ====

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

{{:blog:2024:12:10:m24c02_addressing.png?400|m24c02}}

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.


==== write protection pin ====

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:

{{:blog:2024:12:10:m24c02_nwc_pin_note.png|!WC pin note}}

...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.


===== ending though =====

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.
blog/2024/12/10/2024-12-10_-_m24c02_eeprom_rant.txt · Last modified: 2024/12/10 22:04 by basz
Back to top