i2c eeprom maximum addressable memory locations

Status
Not open for further replies.

sreepss

Full Member level 4
Joined
Jun 10, 2009
Messages
204
Helped
29
Reputation
60
Reaction score
27
Trophy points
1,308
Location
Cochin, Kerala, India
Visit site
Activity points
2,376
Good day everybody
I am doing a project where I am using a 256 Kbit eeprom (Atmel 24xx256). I need to map the whole memory location to store various parameters in to it. My doubt is that what will be the maximum addressable location that we can use in that eeprom?. Is that 512Kbit represents (128 x 1024)/8= 32768 bytes? But when I implemented a circular queue writing method, I can writhe more than this(128x1024=262144 exactly) so I got confused is that 256kbit or 256 kbyte?
 

Hi,

I wonder why you have doubts:

Page one of the datasheet, top right corner:


Klaus

Added:
256kbit = 256 x 1024bits = 256 x 1024 / 8 bytes = 32768 bytes.
I don´t understand both your calculations
 

They mentioned that "The AT24C128/256 provides 131,072/262,144 bits of serial electrically erasable and programmable read only memory (EEPROM) organized as 16,384/32,768 words of 8bits each"
 

Hi,

In your first post you talk about 24xx256. = 256 kbit, like the datasheet clearly says.
But
Is that 512Kbit represents (128 x 1024)/8= 32768 bytes?
Is very confusing.
Why now 512kbit?
Why 128 x 1024?
And your calculation in total is not correct: ( 128 x 1024) / 8 = 16384, not 32768 as you wrote
And your next calculation isn't correct either: 128x1024=131072, not 262144 as you wrote.

***
In your next post you additionally talk about 24C128....to cause even more confusion.

******
I recommend to use a calculator.
And I recomment to read only one datasheet at a time and do the calculations only on this datasheet.
Don't mix different devices within one calculation.

Klaus
 

Ohh sorry Kalus.. Its my mistake, because you referred a datasheet of 256kb. Irrespective of the memory device, what could be the basic calculation that we can use to calculate the maximum usable memory address we can incorporate? . I need to fix the address pointer based on this calculation. According to my knowledge, these are the maximum address an eeprom can store

128k bit flash -- (128 x1024)/8 = 16384bytes
256k bit flash -- (256 x1024)/8 = 32768 bytes
512k bit flash -- (512 x1024)/8 = 65536 bytes
so this is the maximum values that can a eeprom store. Am I correct mr Klaus
 

Hi,

Now your calculations are correct.

16384 means locations 0....16383, = 0x0000 .... 0x3FFF
32768 means locations 0.... 32767, = 0x0000 .... 0x7FFF
65536 means locations 0 .... 65535, = 0x0000 .... 0xFFFF.

Klaus
 

Hi Klause, here my problem starts,
Lar time when I was tested with 128kb eeprom I can able to read and write up to 128 x 1024 locations !!!! Means I had written mt test word (AA) up to 131072 locations ... I am using atmega 2560 with arduino boot loader. Hers my code

writes a byte of data in memory location addr
void writeData(unsigned int addr, byte data)
{
Wire.beginTransmission(i2caddr);
// set the pointer position
Wire.write((int)(addr >> 8));
Wire.write((int)(addr & 0xFF));
Wire.write(data);
Wire.endTransmission();
delay(10);
}

// reads a byte of data from memory location addr
byte readData(unsigned int addr)
{
byte result;
Wire.beginTransmission(i2caddr);
// set the pointer position
Wire.write((int)(addr >> 8));
Wire.write((int)(addr & 0xFF));
Wire.endTransmission();
Wire.requestFrom(i2caddr,1); // get the byte of data
result = Wire.read();
return result;
}

Is there anything wrong ��
 

Hi,

when you write only "AA" into the memory cells you are not able to detect an address wrap around.

If you continously write the numbers from 0 to 254 (ot 255) then starting with 0 again, then you are able to detect wrap around.
(An address wrap around is always with a number of 2^n (= 256, 512, 1024...)

And with alomost any memory access when you access not defined address areas:
* either you get back random nubers (seldom)
* or you get back the status of address lines (often with muxed address / data lines like with AVR external meomory interface. parallel interafce)
* or you get back 0x00 or 0xFF (sometimes, if pullup or pulldowns are installed at address lines. parallel and serial interface)
* or you get back data form other address areas. (often. parallel and serial interface. ) I assume this is your case.

Klaus
 

Hi Klaus,
Sorry for the late replays. I have tried as you suggested but have a look on the screen attached to this post. I have tried with a 512Kbit eeprom, hence the maximum addressable location will be (512 x1024)/8 = 65536 bytes, Is It?. But you can see in the screen that it has already crossed that limit. and still writing in to the locations :thumbsdown:
 

Hi,

did you understand what I meant with "wrap around"?

You have two address bytes to access the memory cells in the EEPROM. (2 bytes, each 8 bits = 16 bits)
You can not address more than 0..65535. It is not possible.

***
You should write the complete memory...and then read/verify the contents and compare it with the expected values.

***

I´m not sure about your compiler: How is an unsigned INT defined? How many bits?

Klaus
 

Hello Klaus,

Thank you very much for your concern. I am using Arduino Studio to compile my code. can you please give an example to write the entire memory?

in my understanding, the wrap around is, the maximum address before the memory over-write its first location. am I correct?

can you please explain the 16 bit addressing method?
 

Hi,

your both screen contents do not match.

On the left side i is counting form 0 to 65500
On the right side the counter is at 67300+.
How can this be?

***
imagine a memory with 4 locations.
The addresses are: 0, 1, 2, 3 in decimal
or 0b00, 0b01, 0b10, 0b11 in binary.
but with an SPI you transmit byte wide = 8 bits wide.
so you transmit 0b00000000, 0b00000001, 0b00000010, 0b00000011
the memory decodes only the most right two bits.

Now you try to access 8 address locations:
0b00000000 ...0b00000111
from 0 to 3 (decimal all is normal)
but if you write data to address 0b00000100, then the memory chip decodes only the most right two bits and sees "00".
So it writes the data to address 0b00000000 (it stores the value in decimal address 0 instead of your suggested address 4)
Now you try to read/verify the contents of address 0b00000100. But as before it accesses the address 0b00000000, too.
so you get back the expected value (= wrong "good"), but it is written and read form the wrong address location.

***
To avoid that wrong "good" condition you need two loops.
One that writes the whole memory area you want to check..
Then in a second loop you read/verify the whole area.

***
Back to the 4 locations emory example.
You write data from 0 to 7 in address locationa 0..7. (At least you try..)
with address 0..3 everything is O.K.
--> with writing data "4" into location "4" you indeed write to location "0". You overwrite the previously written data "0".
(here is where the wrap around happens)
the same is with locations 5...7

Now with the verify loop you read the content of location "0" and expect data "0", but you read back data "4"..
The verify says there was a wrap around.

Klaus
 
Reactions: sreepss

    sreepss

    Points: 2
    Helpful Answer Positive Rating
Hi Klaus. It is a nice explanation .

your both screen contents do not match.

On the left side i is counting form 0 to 65500
On the right side the counter is at 67300+.
How can this be?

This I have made to show you that I can write the locations beyond the calculated memory. So I have started the address pointer from 65500

can you please guide me to implement the correct method to resolve my issue?

these are the things I need to

1. Write a string of bytes ( say 40 byte wide) need to be written in EEPROM, and retrieve the string . Like <1st byte><2nd byte><3rdst byte>.....<40th Byte>

2. Once the memory was filled , I need to write the next sting in the first location (Circular Queue method)

Can you suggest me a good method to implement this?

2.
 

Status
Not open for further replies.

Similar threads

Cookies are required to use this site. You must accept them to continue using the site. Learn more…