Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Help needed with I2C EEPROM


  • Please log in to reply
41 replies to this topic

#1 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 08 November 2010 - 10:26 PM

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:
Attached File  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!!)

#2 freds

freds

    Advanced Member

  • Members
  • PipPipPip
  • 61 posts

Posted 08 November 2010 - 10:38 PM

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.

#3 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 08 November 2010 - 11:07 PM

That may be the issue. Here's the protocol:
Attached File  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...

#4 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 08 November 2010 - 11:43 PM

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 Posted Image I have re-flashed the firmware and performed full erase dozen times...

#5 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 08 November 2010 - 11:49 PM

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.

#6 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 22 November 2010 - 12:27 AM

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

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 22 November 2010 - 12:56 AM

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

#8 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 24 November 2010 - 03:24 AM

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.

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 November 2010 - 04:14 AM

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

#10 freds

freds

    Advanced Member

  • Members
  • PipPipPip
  • 61 posts

Posted 24 November 2010 - 05:03 AM

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.

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 November 2010 - 05:06 AM

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

#12 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 24 November 2010 - 07:42 AM

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.

#13 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 November 2010 - 07:45 AM

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

#14 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 24 November 2010 - 11:42 AM

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!

#15 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 26 November 2010 - 02:09 AM

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!

#16 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 26 November 2010 - 02:23 AM

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.

#17 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 26 November 2010 - 03:02 AM

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

#18 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 26 November 2010 - 03:10 AM

(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 */

#19 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 26 November 2010 - 07:19 AM

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.

#20 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 26 November 2010 - 07:41 AM

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 (VCC).




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.