Auto-Dectect EEProm Size

[DynamoBen]

I currently using the following code to detect the size of a new EEProm prior to formatting.

Address VAR WORD
CounterA var byte
EpromType VAR byte
Control CON %10100000

Address=65535
For CounterA=5 to 1 step -1
I2CWRITE PORTC.4,PORTC.3,Control,Address,[CounterA]
PAUSE 10
Address=(Address>>1)
Next CounterA
I2CREAD PORTC.4,PORTC.3,Control,65535,[EpromType]

Since you are reading just the LAST byte in the SEEPROM, the answer in
EpromType will be a value between 1 and 5, where 1=24LC32 and
5=24LC515.

However I now am looking to use a 16K EEProm. The lowest this loop will go is 32K.

I would like two bits of info. 1) How can I modify this code to calculate all the way down to 1K? 2) Could someone give me a description of how and why this works?

[Melanie]

Woo-hoo!

First posted on 6 November 2002 and somebody is still using the code... gives you a kinda warm glow inside (or is it the Vodka & Lime) and makes it all worthwhile!

This works on the fact that EEPROM Addresses WRAP AROUND... let me explain (since I'm the original author of this ditty)...

You have address 65535... here it is in Binary...

%1111111111111111

When you write DATA to a 64kb EEPROM (24LC512) in this chip you will get your DATA written to that location. But if you had a 32Kb EEPROM (24LC256), it can't see bit 15 and ignores it. All it actions are the lower bits of the address like this...

%0111111111111111

(we're counting from Bit 15 down to and including Bit zero), so it would write your Data into location 32767 and not 65535 because it wraps. So, address 32768 will actually cause a write into address zero in this chip.

So what we are doing is exploiting this feature.

This routine writes the following DATA into the following Addresses...

Address=%1111111111111111 Data=5
Address=%0111111111111111 Data=4
Address=%0011111111111111 Data=3
Address=%0001111111111111 Data=2
Address=%0000111111111111 Data=1

We then do a READ operation for Address 65535... if it's a 24LC512, it will genuinely read-back a 5 from that Address, but a 24LC256 will (expoiting the addressing wrap feature) ignore the top bit and read back from address 32767 and see a 4. A 24LC128, ignores the two top bits from its addressing and will see a 3. A 24LC64 ignores the three top bits and reads back a 2, and a 24LC32 pro-rata reads back a 1.

The routine isn't valid for EEPROMS smaller than a 24LC32 (do people still use those?) because their Page Addressing arangement is different. You need to create a new routine for those baby EEPROMS. Not impossible, just use the same feature demonstrated here.

[DynamoBen]

Fair enough that does help. That being said I really do need a routine for those "baby" EEProms (2000 bytes is nothing to scoff at)

I have read through the AN690 written by micro chip but am having a problem interpalting that to PICBasic.

The example they give is written in a pseduo language:

EXAMPLE 1:
function TestIfSizeIs(Size N): boolean
( // is memory range 0..N-1 ?
var TEMP;
TEMP = Read( 0000);

if ( Read( N) == TEMP)
Write( 0000, TEMP+1)

if ( Read( N) == TEMP+1)
Write( 0,TEMP-1)
return( TRUE)
// else
return( FALSE)
) //end function

Having this function, we can then set up a loop to test
memory sizes.

In the case of the Standard I2C, we can loop and test
from N=128 to N=2048 corresponding to models from
24C01 up to 24C16 doubling N at each iteration as in
the following:

EXAMPLE 2:
function StandardI2CMemDetect() : integer
( // returns a model number 1..16
N = 128
MODEL = 1
loop
if (TestIfSizeIs( N))
break
else
N=N*2
MODEL=MODEL*2
while(N<=2048)
return ( MODEL);
) //end function

Similarly, a function to measure Smart Serial memories
will loop with N=4096 up to N=32768.

Thoughts?

[Melanie]

Microchip Application Notes should really be taken with a liberal pinch of salt. Use them as a guide only as to the theory of what you're trying to achieve. Beyond that a lot of them are seriously misleading and erroneous.

OK... I've thrown this together... deliberately written in a long-winded fashion so you can follow the code... try it... see what happens...


Address var Byte
CounterA var Byte
EpromType var Byte
Control var Byte

For CounterA= 5 to 1 Step -1
Address=%11111111
Control=%10100000
If CounterA=5 then Control=%10101110
If CounterA=4 then Control=%10100110
If CounterA=3 then Control=%10100010
If CounterA=1 then Address=%01111111
I2CWRITE SDA,SCL,Control,Address,[CounterA]
Pause 10
Next CounterA
Address=%11111111
Control=%10101110
I2CRead SDA,SCL,Control,Address,[EpromType]
If you want to know where I got the figures from, just look at the table in the I2CREAD command in the PBP manual.

This should write a byte in the last memory location of each of the five sizes of chip...

Into a 24LC16 at address 2047 it will write a 5
Into a 24LC08 at address 1023 it will write a 4
Into a 24LC04 at address 511 it will write a 3
Into a 24LC02 at address 255 it will write a 2
and into a 24LC01 at address 127 it will write a 1

Naturally if you have a 24LC16 you will end up writing into five memory locations, at each of the addresses. A 24LC08 will have four memory locations written to... with the one at 1023 being written to twice... first with a 5 then overwritten with a 4. The 24LC04 will have three addresses written to, but it's top one will be written to three times, first with a 5, then with a 4 and finally with a 3. The 24LC01 will only have one address written to, but it will be written five times, first with a 5, then a 4... etc until finally it gets a 1.

When reading back, by selecting Address 2047, chips that cannot access that high will read-back the highest memory address that they can (ignoring the higher bits), and in so doing so, the variable EpromType will hold the number identifying the type of chip you've got installed.

Like I mentioned in my original reply, all we've done is taken the same routine and principals and rehashed them for the Page addressing of the baby sized EEPROMs.

I'm sure you can test this and report back if it works, as unfortunately I don't have anything smaller than a 24LC64 in stock.

ooops... found a small error in the code which I corrected this morning 7am 17 June, so anyone copying the code before that please check.

[aberco]

I updated Melanie's code which did not behaved as expected on small EEPROMs. Here's the new topic: EEPROM automatic identification routine (http://www.picbasic.co.uk/forum/showthread.php?t=13778)