EEPROM 24AA01 Write Protection Problem

Status
Not open for further replies.

muragavino

New Member
Hello!

I am using the 24AA01 on 3 identical prototypes and have the same problem on all 3: I can read and write to the chip, but whatever I write to the chip it will allways read 0xFF instead of the data written. The "Acknowledge Polling" after the write instruction allways returns instantly with ACK=0. Waiting e.g. 15 msec after the writing, gives anyway the same result. I tried also with pin WP tied physically to Vcc and have the exact same polling response as with WP tied to Vss (GND). Vcc is 3.3V and my I2C clock frequency for testing is 10 KHz, but I also tried with 100 and 400 KHz.
Attached is a picture from my oscilloscope with the I2C levels for writing with ACK polling (track 1 and 2) and subsequent reading (track 3 and 4).

Can anybody help?

Thanks!
Michael
 
Hello Geko, thanks for the quick response. If you look closely, in the lower right half of the picture, where the only read is performed, the control byte is actually 0xA1, so the read bit is correctly set. The I2C routines I use here work without problems on other devices.
Anyway thanks, every little bit helps!
 
If you read directly after a write.. The write will fail.. You have to wait 5mS~ 10mS before reading...
 
Hi Ian, it would be lovely if it would be that easy! Unfortunately you can wait as long as you like between the write and the read - it always returns 0xFF.
Thanks anyway!
 

Sorry, it was the way it was annotated, my mistake.
 
Hi Ian, it would be lovely if it would be that easy! Unfortunately you can wait as long as you like between the write and the read - it always returns 0xFF.
Thanks anyway!
Oops, sorry just re-read the first post.... I'm looking at your "read" sequence... Where is the "re-start" code.. Your read sequence seems far to small are you missing half of your "Word" address???
 
Scratch that!! The datasheet is nonsensical It talks of "Word Addressing" then talks about an 8it word??????

 
Everything looks good to me, up until your restart. It looks to me like your sda line is rising as your scl line is falling, or maybe just slightly before scl is properly low
 
I think you are correct tunewolf on analysing the sda and rising scl are too close for comfort, not only on that restart but everywhere..
 
Yea, I was looking at it from a protocol perspective, rather than a timing one, but you're right, it is a little close. I would imagine this will work perfectly with nice short fat traces and good decoupling, but introduce any parasitics into the equation and the timing may very well be violated.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…