has anybody any experience with AT24CS family of Atmel EEPROMs? I have here AT24CS64 on my table and I'm trying how "official" I2Cscanner sketch works with it. I'm confused because only one I2C address is found - 0x50. I'm pretty sure that there should be also another I2C address recognized inside the EEPROM, because chip includes also an unique serial number on the address which should be 0x08 higher than "main" address, so 0x58, but it is not recognized by sketch. Am I doing something wrong?
A quick read thru of the datasheet would lead me to agree with you. Mind you, it was a quick read thru so I possibly could have missed something.
Have you tried a serial number read to see it actually works? Is there a possibility that you don't really have a 24CS (i.e. did you buy it from a reputable distributor)?
Edit: it might be illuminating to see the results of a version of the I2C scanner sketch modified to scan the addresses in descending order.
The I2C scanner provides the address of the device you need to communicate with. You must send the chip a command specifying what you want to do, and then read or write data to or from the chip using the I2C protocol. This system is essentially a variation of a multiplexing method designed to save microcontroller ports.
I might have misunderstood the datasheet but it looks like access to the unique serial number starts with the address and the read/write bit clear - i.e. a write - figure 10.4 in the datasheet. It's shown as a dummy write. I think the I2C scanner always attempts a read access and then looks for an ack or nak.
If that's the case, then the I2C scanner won't detect the additional address as the device won't respond to a read.
From the internet: The I2C scanner works by sending signals to each possible I2C address on the bus and checking for a response from any connected devices. If a device acknowledges the address, it indicates that the device is present and functioning on the I2C bus.
After the start condition, the next byte that appears on the I2C bus holds the 7-bit device address and 1 bit (in the LSB of that byte) that tells the device if it's a read or a write.
The I2C scanner outputs a byte indicating a read to see if it gets an ack or nak back.
The AT24CS64 datasheet suggests that in order to get a response from the serial number address, it must be a write. That may be why the I2C scanner doesn't detect the additional address occupied by the chip.
thanks for your replies. @van_der_decken
I'm sure that device is really AT24CS, I bought it from official distributor.
Changing order of searching mode doesn't help.
@markd833
It looks like that Serial Number access area is read only, so it is not sure why reading don't work.
I tried to find out all differences between EEPROM access area (it is available on 0x50 in my example) and Serial number access area (it should be available on the address which is 0x08 higher than EEPROM access area, so 0x58 in my example).
As it looks like, I2C scanner sketch uses Wire.beginTransmission() function which is usually used in combination with Wire.write() function. I'm not sure if this could be a reason, but there is no possible to write in to Serial Number access area, so it is read only area. Could be this a reason why device doesn't respond on Wire.beginTransmission() function call?
Many thanks!
//edit @markd833
I didn't see your last post before I started writing mine. I'm also now thinking that something could be connected with a fact that Serial Number area is read only and it is not possible to write anything into...
Procedure of read operations from Serial Number access area (Figure 10-4) in a datasheet shows that firstly is needed to write on that address, to "unlock" specific area with Serial number...I'm really confused, since it looks like that trying to write on address with Serial number access area should return something?
It may be that there is a bug in I2C scanner, or not. Doesn't appear to be much detailed documentation about "i2c scanner", and there are different versions.
I would put that aside, and try the sequence described in Figure 10-4.
You beat me to it. I was about to post that same figure from the datasheet to explain myself further.
As you can see, the first byte (on the left) is the device address with the read/write bit clear - i.e. it's a write command - because a dummy write is needed first to unlock read access to the serial number.
The I2C scanners - I THINK - send out device addresses with the read/write bit set - i.e. a read command - and see if an ack comes back. I would hazard a guess that the chip won't respond to a read command with an ack unless it's just had a write sequence as shown in fig 10-4.
It looks like the write bit is being set for each device address. A NAK is detected until address 0x50 is queried where a device exists and an ACK is received.
For completeness, I also ran a scan with Rob Tillaarts I2C scanner library and that too sets the write bit:
// --------------------------------------
// i2c_scanner
//
// Version 1
// This program (or code that looks like it)
// can be found in many places.
// For example on the Arduino.cc forum.
// The original author is not know.
// Version 2, Juni 2012, Using Arduino 1.0.1
// Adapted to be as simple as possible by Arduino.cc user Krodal
// Version 3, Feb 26 2013
// V3 by louarnold
// Version 4, March 3, 2013, Using Arduino 1.0.3
// by Arduino.cc user Krodal.
// Changes by louarnold removed.
// Scanning addresses changed from 0...127 to 1...119,
// according to the i2c scanner by Nick Gammon
// https://www.gammon.com.au/forum/?id=10896
// Version 5, March 28, 2013
// As version 4, but address scans now to 127.
// A sensor seems to use address 120.
// Version 6, November 27, 2015.
// Added waiting for the Leonardo serial communication.
//
//
// This sketch tests the standard 7-bit addresses
// Devices with higher bit address might not be seen properly.
//
#include <Wire.h>
void setup()
{
Wire.begin();
Serial.begin(9600);
while (!Serial); // Leonardo: wait for serial monitor
Serial.println("\nI2C Scanner");
}
void loop()
{
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for(address = 1; address < 127; address++ )
{
// The i2c_scanner uses the return value of
// the Write.endTransmisstion to see if
// a device did acknowledge to the address.
Wire.beginTransmission(address);
error = Wire.endTransmission();
if (error == 0)
{
Serial.print("I2C device found at address 0x");
if (address<16)
Serial.print("0");
Serial.print(address,HEX);
Serial.println(" !");
nDevices++;
}
else if (error==4)
{
Serial.print("Unknown error at address 0x");
if (address<16)
Serial.print("0");
Serial.println(address,HEX);
}
}
if (nDevices == 0)
Serial.println("No I2C devices found\n");
else
Serial.println("done\n");
delay(5000); // wait 5 seconds for next scan
}
It looks like that this is Nick Gammon's I2C scanner. I will try scanner made by Rob Tillaarts and I will let you know about the results.
I made some additional tests just now. Before that I changed (from the hardware point of view) IC's address of the EEPROM access area from 0x50 to 0x51 (this means that Serial number access area moved to 0x59), to check if there would be some change.
The test would be to hit the reset button and make sure you get the same values again. But yes, that looks valid to me.
I think the problem with the I2C scanners is that the CS chip just isn't designed to respond to an initial Read of 0x58 at all, as proposed by @markd833 in post #10. So it doesn't show up during the scan. But my code shows it does respond to the dummy write of the data address (0x0800) where the serial number is located.
Unless I completely messed up, I disproved what I thought was a sound theory back in post #12. From my very basic checks, both Nick Gammon's and Rob Tillaart's I2C scanners put out the address with the R/W bit clear - i.e. a write.
That one byte should have been enough to cause an ACK from the secondary device address according to fig 10-4 of the datasheet (as shown in post #8). I'm at a loss as to why the I2C scanner didn't pick it up.
@ShermanP
I can confirm that I get same number every time, so values are right.
It is still interesting question why I2C scanners don't find anything. However, Nick Gammon's based scanner returns error on the address where Serial number is, this means that something should be different enough that scanners are completly "lost".
Serial monitor returns meaningful values to me: