41 replies to this topic

[osno]

I've been trying for a few days to get an 24LC256 EEPROM working. I'm in a point where the bytesTransferred I receive from the I2CTransaction is correct for both Write and Read, but when I inspect the buffer for the read operation, it's all 255's (every byte is maxed out). I think it has something to do with the resistors I'm using. I tried 2k connected to 5V and 3.3V and 10k connected to 5V and 3.3V and I get the same in all combinations. If I remove the pull-up's completely, the read operation reports 2 bytes transferred (the address I'm writing, I'm assuming). If anybody can help, I'll be more than grateful.

This is how I'm wiring everything. The digital pins are connected to a 74HC238 to show me some output from what I'm saving. I only drew a few leds... there's more. That part seems to work, though. The graphic:
 EEPROM.png   54.37KB   150 downloads

And the code for the memory driver is:

        public byte[] ReadBytes(ushort address, int length)
        {
            byte[] data = new byte[length];

            using (I2CDevice eeprom = new I2CDevice(new I2CDevice.Configuration(0x50, 400))) //0x50 is 1010 000, 400 is 400khz
            {
                // Create a new Transaction 
                I2CDevice.I2CTransaction[] transaction = new I2CDevice.I2CTransaction[]{
                    I2CDevice.CreateWriteTransaction(new byte[] { (byte)((address >> 8) & 0x7F), (byte)(address & 0xFF) }),
                    I2CDevice.CreateReadTransaction(data)
                };
    
                int bytesTransfered = eeprom.Execute(transaction, 1500);

                if (bytesTransfered == length + 2)
                    return data;
                else
                    return null;
            }
        }

        public void WriteBytes(ushort address, byte[] data)
        {
            using (I2CDevice eeprom = new I2CDevice(new I2CDevice.Configuration(0x50, 400))) //0x50 is 1010 000, 400 is 400khz
            {
                // Create a new Transaction 
                I2CDevice.I2CTransaction[] transaction = new I2CDevice.I2CTransaction[]{
                    I2CDevice.CreateWriteTransaction(new byte[] { (byte)((address >> 8) & 0x7F), (byte)(address & 0xFF) }),
                    I2CDevice.CreateWriteTransaction(data)};

                // Execute the WriteBytes transaction, check if it was succesfull.
                int bytesTransfered = eeprom.Execute(transaction, 1500);
            }
        }
    }

The program does:

            byte[] sequence = new byte[]{ 2, 1, 2, 3, 2, 1, 0, 3, 1, 2, 0 };
            byte[] data = new byte[11];

            board.Memory.WriteBytes(100, sequence);
            data = board.Memory.ReadBytes(100, 11);

And then loops flashing the leds.

Thanks in advance to any kind soul who can take a look and give me some advice. I have tried 2 different EEPROM chips (same type) to the same result. Many resistor/voltage combinations. Even reversing the SDA and SCL (that didn't help ). I don't know what to try at this point.

Thanks again,
J

(formatting tips are also appreciated... other people's posts look way better than mine!!)

[freds]

I've been trying for a few days to get an 24LC256 EEPROM working. I'm in a point where the bytesTransferred I receive from the I2CTransaction is correct for both Write and Read, but when I inspect the buffer for the read operation, it's all 255's (every byte is maxed out). I think it has something to do with the resistors I'm using. I tried 2k connected to 5V and 3.3V and 10k connected to 5V and 3.3V and I get the same in all combinations. If I remove the pull-up's completely, the read operation reports 2 bytes transferred (the address I'm writing, I'm assuming). If anybody can help, I'll be more than grateful.

Thanks in advance to any kind soul who can take a look and give me some advice. I have tried 2 different EEPROM chips (same type) to the same result. Many resistor/voltage combinations. Even reversing the SDA and SCL (that didn't help ). I don't know what to try at this point.

Thanks again,
J

(formatting tips are also appreciated... other people's posts look way better than mine!!)

Not sure if this device requires a repeated start bit, if so CW2 just posted firmware and managed code to support this type of operation.

I2CDevice extension Support for Repeated Start condition

Also when my device which needed this type of operation and wasn't working the returned values were all 0xFF.

[osno]

That may be the issue. Here's the protocol:
 protocol.png   33.25KB   66 downloads

I think that after the Write, I should be sending the start again. Can I do that by doing this?

            byte[] data = new byte[length];

            using (I2CDevice eeprom = new I2CDevice(new I2CDevice.Configuration(0x50, 400))) //0x50 is 1010 000, 400 is 400khz
            {
                // Create a new Transaction 
                I2CDevice.I2CTransaction[] transaction = new I2CDevice.I2CTransaction[]{
                    I2CDevice.CreateWriteTransaction(new byte[] { (byte)((address >> 8) & 0x7F), (byte)(address & 0xFF) }),
                };
                eeprom.Execute(transaction, 1500);
            }

            using (I2CDevice eeprom = new I2CDevice(new I2CDevice.Configuration(0x50, 400))) //0x50 is 1010 000, 400 is 400khz
            {
                // Create a new Transaction 
                I2CDevice.I2CTransaction[] transaction = new I2CDevice.I2CTransaction[]{
                    I2CDevice.CreateReadTransaction(data)
                };
                int bytesTransfered = eeprom.Execute(transaction, 1500);

                if (bytesTransfered == length + 2)
                    return data;
                else
                    return null;
            }

Because I tried it, but it didn't work either...

I may be forced to reflash. I didn't want to brick my netduino .

Anyway, my problem. Thanks! I'll try that...

[CW2]

That may be the issue. Here's the protocol:

Yep, the EEPROM requires Repeated Start. Unfortunately, my I2CDevice extension will not work for you, because it is limited only to 1 byte internal address, while the EEPROM requires two - high and low. I can update the code to support your device - if you are interested in testing, please contact me via private message.

I think that after the Write, I should be sending the start again. Can I do that by doing this?

Unfortunately, each transaction is terminated with a stop condition (start - write - stop, start - read - stop), Netduino microcontroller requires special handling of start - write - start - read sequence.

I may be forced to reflash. I didn't want to brick my netduino .

You don't have to be afraid, it is actually very difficult to brick Netduino just by flashing I have re-flashed the firmware and performed full erase dozen times...

[osno]

I had tested before I read your message. PMing you now. Thanks!! I plan on writing a big-ass blog post if this works, if you don't mind.

[Charles]

Is this fix integrated into the latest Netduino/N+ firmware?

[Chris Walker]

Is this fix integrated into the latest Netduino/N+ firmware?

Hi Charles,

The latest Netduino firmware uses the Microsoft/Atmel I2C implementation. We're looking at ways to extend this using the community contribution, but nothing official yet. You can of course use one of the custom firmwares or build your own, and we hope to have something enhanced in the main trunk available before too long as well...

Chris

[Charles]

Hi Charles,

The latest Netduino firmware uses the Microsoft/Atmel I2C implementation. We're looking at ways to extend this using the community contribution, but nothing official yet. You can of course use one of the custom firmwares or build your own, and we hope to have something enhanced in the main trunk available before too long as well...

Chris

Except none of the custom firmwares out there have PWM support.

[Chris Walker]

Charles, We'd also be happy to compile one or two of the firmwares with the beta PWM code in it... Any takers? Chris

[freds]

Charles,

We'd also be happy to compile one or two of the firmwares with the beta PWM code in it... Any takers?

Chris

Yes I need repeated start with analog input and PWM for my project.

[Chris Walker]

CW2, How about if we compile your I2C extensions with the v4.1.0.6 firmware and the beta PWM code? Using RVDS? Anything else we should compile in there at the same time? Chris

[CW2]

How about if we compile your I2C extensions with the v4.1.0.6 firmware and the beta PWM code? Using RVDS?

That would be nice. But I have to publish or send you the latest version that supports multi-byte Internal Address, which is required for serial EEPROM's random read - I'll do it when I get back from work. I have tested the code with 24LC64, I will check if I can get 24LC256 today.

[Chris Walker]

Okay, cool. Just PM me when you're ready. Chris

[osno]

I got completely sidetracked on other things and couldn't test this appropriately, sorry for that. I'd love to see that code in the official firmware, though!

[Charles]

Could someone glance at this page: http://www.atmel.com...nts/doc5297.pdf And tell me if this EEPROM module would work with the stock firmware? It doesn't appear to have the same start signal problem, but I'm not familiar enough with the firmware's capabilities to know if it would work or not. Thanks!

[osno]

I think it has the exact same problem (Device Address -> Write needed memory address -> device address repeat). Some of the guys here can confirm. The problem is that the stock firmware doesn't repeat the device address (that is, you can't request device -> write -> device -> read in a single instruction). Check the sequence in page 11 here: http://www.sparkfun....IC/24LC256.pdf. One calls it control byte and the other device address, but the sequence is basically identical.

[Charles]

Great.... Any idea where I would find the unusual EEPROM chip that operates with this firmware? ...which seems to be the only chip the firmware writer happened to have on hand when they were testing this code... Charles

[Omar (OZ)]

(formatting tips are also appreciated... other people's posts look way better than mine!!)

Hey,
As far as the schematic goes... It seems that you don't know how to change the direction of the wires in Fritzing. I had no clue how to do it at first and it drove me nuts. So to change the wires' direction select one and click and drag on the wire (not the end points) and it will make a new 'joint' that you can move around. Also to snap the joints at 90/45 degree angles use the Shift key while dragging.

If you knew the above already sorry if this offended you.

EDIT:
I had some free time so I decided to re-make your schematic.. please note before using my re-make check to make sure it matches with the original in case I overlooked something. I decided to do this to help not to criticize by the way, what you are doing is something that I am not ready to do yet (too advanced for me)! so I made this to save you a little time

/* I am fixing it, I'll repost later */

[CW2]

The problem is that the stock firmware doesn't repeat the device address (that is, you can't request device -> write -> device -> read in a single instruction).

I have updated version of I2CDevice extension firmware that supports multi-byte Internal Address, which is required by serial EEPROMs. I have verified that the code works with 24LC64 and 24LC256 Microchip memories, I can publish it for testing if there is enough interest - I postponed it for now, because Chris Walker offered to include the workaround in official 4.1.0.6 version, that also contains PWM code.

[CW2]

I had some free time so I decided to re-make your schematic.. please note before using my re-make check to make sure it matches with the original in case I overlooked something.

Oz, you accidentally flipped the EEPROM chip in your schematic. Additionally, if your breadboard is same as mine, there is a missing connection between bottom and top ground lines; and I would rather connect the pull-up resistors to 3.3 V (V_CC).