I have no way to test this, but at least it compiles. It reads the address at the beginning of each of eight pages, then writes a new different value to each of those locations, then reads them all again to see if the new values took. If it all works, that would indicate it acts like a C16, and has at least 2048 bytes.
#include <AT24C16.h>
AT24C16 rom; // Initializing AT24C16 Library with the object named rom. Default slave id = 0x50
void setup() {
Serial.begin(9600); // Initializing Serial at 9600 bps.
while (!Serial) {
; // wait for serial port to connect
}
Wire.begin(); // Initializing I2C protocol (Master Mode)
// READING OPERATION
Reading_operation(); // EXECUTING READING SUB-ROUTINE
// WRITING OPERATION
Writing_operation(); // EXECUTING WRITING SUB-ROUTINE
// READ AGAIN
Reading_operation(); // EXECUTING READING SUB-ROUTINE
}
void loop()
{
//Nothing Here
}
void Reading_operation() // READING FUNCTION
{
Serial.println(F("Reading previously stored values from EEPROM chip...."));
Serial.println();
Serial.println(F("Address \t Value (HEX)"));
Serial.println(F("========================"));
// Loop for reading one byte from each of 8 pages
int i = 0;
while (i < 2048) {
byte eepromData; //1 byte data storage
//Reading 1 byte of data from EEPROM chip and store that value in eepromData. Here (i) represents the location address.
rom.Read(i, &eepromData);
Serial.print (i); //Printing Location address
Serial.print(F("\t\t"));
Serial.println(eepromData,HEX); //Printing value (in HEX format) which we get from eeprom.
i += 256;
}
Serial.println(F("Reading Done.")); Serial.println();
}
void Writing_operation() // WRITING SUB-ROUTINE
{
Serial.println(F("Writing new values into EEPROM chip at start of each page"));
Serial.println();
Serial.println(F("Address \t New Value (HEX)"));
Serial.println(F("========================"));
int i = 0;
byte newValue = 0;
while (i < 2048) {
rom.Write(i,newValue); // Writing 1 byte of data into EEPROM chip. Here (i) represents target location address.
Serial.print (i); //Printing Location address
Serial.print ("\t\t");
Serial.println(newValue,HEX); //Printing value (in HEX format) which we write to eeprom.
i += 256;
newValue += 0x10;
}
Serial.println(F("Writing Done")); Serial.println();
}
That library appears to work. I've simplified the code muchly for my test:
#include <AT24C16.h>
AT24C16 rom; // Initializing AT24C16 Library with the object named rom. Default slave id = 0x50
void setup()
{
Serial.begin(9600); // Initializing Serial at 2000000 bps.
Wire.begin(); // Initializing I2C protocol (Master Mode)
for (uint16_t i = 0 ; i < 32 ; ++i) {
uint16_t iByteToWrite = i*3 ;
rom.Write(i,i*3);
uint8_t iByteRead ;
rom.Read(i,&iByteRead);
if (iByteToWrite == iByteRead) {
Serial.print ("Address :") ;
Serial.print (i) ;
Serial.print (" Byte written and read match: ") ;
Serial.println(iByteRead) ;
} else {
Serial.print ("Address :") ;
Serial.print (i) ;
Serial.print (" Byte written: ") ;
Serial.print (iByteToWrite) ;
Serial.print (" , Byte read: ") ;
Serial.println(iByteRead) ;
}
}
}
void loop()
{
//Nothing Here
}
And the results are (first 32 bytes)
Address :0 Byte written and read match: 0
Address :1 Byte written and read match: 3
Address :2 Byte written and read match: 6
Address :3 Byte written and read match: 9
Address :4 Byte written and read match: 12
Address :5 Byte written and read match: 15
Address :6 Byte written and read match: 18
Address :7 Byte written and read match: 21
Address :8 Byte written and read match: 24
Address :9 Byte written and read match: 27
Address :10 Byte written and read match: 30
Address :11 Byte written and read match: 33
Address :12 Byte written and read match: 36
Address :13 Byte written and read match: 39
Address :14 Byte written and read match: 42
Address :15 Byte written and read match: 45
Address :16 Byte written and read match: 48
Address :17 Byte written and read match: 51
Address :18 Byte written and read match: 54
Address :19 Byte written and read match: 57
Address :20 Byte written and read match: 60
Address :21 Byte written and read match: 63
Address :22 Byte written and read match: 66
Address :23 Byte written and read match: 69
Address :24 Byte written and read match: 72
Address :25 Byte written and read match: 75
Address :26 Byte written and read match: 78
Address :27 Byte written and read match: 81
Address :28 Byte written and read match: 84
Address :29 Byte written and read match: 87
Address :30 Byte written and read match: 90
Address :31 Byte written and read match: 93
What does this mean in practice, that AZDelivery have given a working board but with a datasheet referring to a different EEPROM?
Please try my sketch in post #101. This is just to confirm that it really is 2KB.
So if that sketch works, someone should probably notify AZ_Delivery that the chip marked 24C02 on their modules is actually a 24C16 EEPROM, not a 24C32. Moreover, by design the 24C16 responds to all eight addresses 0x50 - 0x57, regardless of what's done to the address jumpers on the module. And they really shouldn't be selling these modules.
Anyway, it's good to be able to figure things out.
Address Value (HEX)
========================
0 15
256 15
512 15
768 15
1024 15
1280 15
1536 15
1792 15
Reading Done.
Writing new values into EEPROM chip at start of each page
Address New Value (HEX)
========================
0 0
256 10
512 20
768 30
1024 40
1280 50
1536 60
1792 70
Writing Done
Reading previously stored values from EEPROM chip....
Address Value (HEX)
========================
0 FF
256 FF
512 FF
768 FF
1024 FF
1280 FF
1536 FF
1792 FF
Reading Done.
Which I have not interpreted. I'm just happy I have a few bytes from 0x0 onwards, that is all I need.
As for informing AZDelivery I agree with arg. They made no effort to help me, for €10 it was probably not worth their time. And I'm certainly not going to spend any more of my time debugging their boards. I only which they would not vaunt their technical ability.
But ShermanP you helped me into getting a way to use it, so thanks for that.
Thanks for running my sketch. The results are not encouraging, so I assume something is wrong with my code. I'll look at it again.
Edit: The second read sequence should produce the same values as the write sequence, not all FFs. I've looked at your simplied sketch, which seems to work, and at mine, which doesn't, and can't see what I've done wrong. It may be writing FFs, or incorrectly reading FFs. Perhaps you or someone else can identify what I need to change. Or perhaps it's not a 24C16 after all.
Edit2: @giovanniguerra, can you modify your sketch to see if you can write to any address beyond 255. In other words, can you write different values to 0 and 256, and read them back as different?
I've just run my test again and the first two bytes are blown. This board's EEPROM is total rubbish. There is no point in testing it further...
Address :0 Byte written: 0 , Byte read: 255
Address :1 Byte written: 3 , Byte read: 255
Address :2 Byte written and read match: 6
Address :3 Byte written and read match: 9
Address :4 Byte written and read match: 12
Address :5 Byte written and read match: 15
Address :6 Byte written and read match: 18
Address :7 Byte written and read match: 21
Address :8 Byte written and read match: 24
Address :9 Byte written and read match: 27
Address :10 Byte written and read match: 30
Address :11 Byte written and read match: 33
Address :12 Byte written and read match: 36
Address :13 Byte written and read match: 39
Address :14 Byte written and read match: 42
Address :15 Byte written and read match: 45
Address :16 Byte written and read match: 48
Address :17 Byte written and read match: 51
Address :18 Byte written and read match: 54
Address :19 Byte written and read match: 57
Address :20 Byte written and read match: 60
Address :21 Byte written and read match: 63
Ok. Thanks for trying it again. Well there were two choices. Either it was a 24C02 that's responding to too many addresses, or it was a 24C16 wrongly marked. I thought it might be the latter, but I think I was wrong. I found this:
So it looks like some 24C02s just behave badly. And on top of that, it looks like your 24C02 was no good even as that. But in the best case, I think this is still a 256-byte eeprom.
You might have blown out some locations during testing, if you happened to load code that wrote to it repeatedly. Did you make any changes to the code in post #102 before the latest test? Did you run any other code in between?
However, I think it's fair to say, it's not worth the effort any more.
In case you want to try it to attempt to recover those two addresses, I found this code that doesn't use a library other than Wire.h. No other libraries with obnoxious pointers.
He ran my code, which attempted to write to the first byte of each of eight pages. But if it's only a 256 byte chip, all of those would have been to location zero. But that's still only eight times, and my code didn't touch location one, which is also bad. So I don't know.
At the very most those locations have been written to 20 times. A bit less than the often stated 100,000 minimum write read operations of most data sheets.
So can anyone recommend a supplier of RTC+EEPROM boards. It it had worked it would have been ideal. As I said I need very few bytes in the EEPROM, less than 50.
It used to be that you could buy these modules from anyone, and they worked fine. But if the manufacturer has started putting these bogus eeproms on them, then I don't think any seller is reliable. But I think Orionis in the other thread has ordered new ones from another source. Maybe you could check with him.
Julian Ilett on Youtube has used the big Chinese Ebay seller alice1101983 in the past, apparently with good results. They have half a million reviews, 99.7% positive. But they won't be better than anyone else if their source has started populating the modules with bogus chips.
I looked up the DS3231 chip on Digikey, and singles now cost $10. So I suspect the cheaper DS3231M will increasingly populate these modules,. They work the same, but don't keep time as well. Maybe Adafruit will become the only reliable source for modules. Well, I think I will order a couple from Alice and see what happens.
