Searching \ for '[PIC]: [EE]: I2C embarassed!!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: '[EE]: I2C embarassed!!'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: [EE]: I2C embarassed!!'
2001\05\07@140222 by Roman Black

flavicon
face
Well i'm I2C embarrased! :o)
After weeks of downloading and printing all the
Microchip appnotes, and the F873 and 24LC256
datasheets, with all been read at least once and
handwritten notes through them, and I2C timing
diagrams up on my wall, and downloading all the
piclist.com I2C source code, and thinking I knew
just about all the secrets to bit-banging I2C to a
serial eeprom, well... It doesn't work.

Yes i've checked appnote AN709 and used their
safety initialisation example. I've allowed around
2uS between any change of state of the SDA or SCL
pins, to keep rise/setup/hold times all safely
well within spec. I disable GIE (with the safe loop)
before doing any I2C stuff.

Hardware? I have 3 indicator leds, one flashes
the data bytes, others to confirm the write or read
control buttons. It is on a "protoboard" that I use
for projects that is kitted with it's own ICSP.
I have a 1k pullup resistor on SDA. Speed is 16MHz,
or 4MHz/inst.

Everything is designed in small simple code modules
that I have checked carefully.

Here's my problem:
* about 10% of the time the ack bit (from eeprom)
fails, ie my code detects ack was high after sending
8 bits. Any read or write to the 24LC256 eeprom
must send at least 3 bytes and receive back 3 acks,
for control, address_hi and address_lo.
* If it manages a read or write without failing an ack
the eeprom read comes back as all zeros. I'm assuming
that no valid write (and possibly no valid read) is
ever taking place.

Any suggestions? This is embarassing, after all the
I2C problems posted here I was determined to do my
homework first and get it right... :o)
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@141439 by Mark Newland

flavicon
face
Haveing just done the same things you did, I know the feeling.  Took me a
couple days to get all the timeing right, etc.  Only thing I think of is
the LED's themselves.  Are they buffered?  I don't know what the
capacitance is on a LED but could it be slowing down the bus?

Roman Black wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@142523 by Roman Black

flavicon
face
Mark Newland wrote:
>
> Haveing just done the same things you did, I know the feeling.  Took me a
> couple days to get all the timeing right, etc.  Only thing I think of is
> the LED's themselves.  Are they buffered?  I don't know what the
> capacitance is on a LED but could it be slowing down the bus?

Thanks Mark, the leds are on different pins and not
on the I2C bus. I know the protoboards have about 50pF
per "row" so I may have as much as 100pF on either SDA
or SCL, but I thought 2uS would be enough. I tried it
with a 4MHz crystal instead, so that took it to 8uS
between any state change of a bus pin. Identical
fault symptoms. I'm stumped.
-Roman



{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@144154 by Jerry Merrill

flavicon
face
Roman:

I fought something like this once.  The problem ended up being related to
R-M-W on the port pins.  Each time I toggled the CLOCK pin, it would latch
the CURRENT state of the DATA pin (which of course can change when the
slave ACKs.  The solution was to restore the DATA pin after each CLOCK
change.  I suppose using shadow registers might of done it as well.

My (CVASM) source for talking to a 24C00 type device is at:

http://www.tech-tools.com

Click on "search" and search for "i2c"


>Any suggestions? This is embarassing, after all the
>I2C problems posted here I was determined to do my
>homework first and get it right... :o)
>-Roman


Jerry Merrill

spam_OUTjerrymTakeThisOuTspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814   VOICE:(972) 272-9392
TechTools  PO Box 462101  Garland,  TX  75046-2101

Join our PIC discussion list at
http://www.tech-tools.com/picsource.htm

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@151443 by Barry King

flavicon
face
Roman,

> Any suggestions?

You don't say whether you've looked at a byte frame on a 'scope  to
confirm the rise and fall times, and the slew between SDA and SCL.
Is SCL held valid low the whole time SDA slews?  Can you do that
test?  The symptom does sure sound like something is wrong with bit
timing, since you don't read back a correct ACK from the EEPROM.

-Barry.
------------
Barry King
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the PIClist Archive!
PIC/PICList FAQ: http://www.piclist.com/faq

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@154916 by Eisermann, Phil [Ridg/CO]

flavicon
face
This is just a stab in the dark, since you seem to have done your
homework...

according to the datasheet, the maximum allowed risetime is 1000ns (1us),
whereas the maximum allowed fall time is 300ns. Have you looked at the lines
with a scope?

{Original Message removed}

2001\05\07@162405 by Olin Lathrop

face picon face
> I have a 1k pullup resistor on SDA.

1K is a bit low.  IIC has a surprisingly low max current sink spec.  If you
are using a 5V supply, the pullup needs to be higher.  I vaguely remember
3mA max, but you should check this.  Also, you specifically mention SDA but
what about SCL?  It should have the same size pullup on it.

> * about 10% of the time the ack bit (from eeprom)
> fails, ie my code detects ack was high after sending
> 8 bits.

This sounds like it could be the Microchip MSSP IIC ACK bug.  Use 2K pullups on
SCL and SDA, never run the bus above 500KHz bit rate, and add a 200pF cap to
SDA.  If that fixes it you probably did hit the MSSP bug.  Then you can
go back and tweak some of the particulars if you wish.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@163636 by Mark Newland

flavicon
face
Troubleshooting tip?:  If after sending your 9th clock pulse you don't get a
AWK, what would happen if you sent it a 10th clock pulse?  Would the slave
think that your 9th pulse was actually your 8th and still waiting for another??

Roman Black wrote:

{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@190406 by Tony Nixon

flavicon
picon face
Roman Black wrote:
>
> Well i'm I2C embarrased! :o)
> After weeks of downloading and printing all the
> Microchip appnotes, and the F873 and 24LC256
> datasheets, with all been read at least once and
> handwritten notes through them, and I2C timing
> diagrams up on my wall, and downloading all the
> piclist.com I2C source code, and thinking I knew
> just about all the secrets to bit-banging I2C to a
> serial eeprom, well... It doesn't work.

If you have a copy of ROMzap MKIII it has a 24LC256 code generator which
is much the same as used in the Pocket.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesspamKILLspampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@193123 by embedded engineer

flavicon
face
Hello Roman,

Roman Black wrote:
> Well i'm I2C embarrased! :o)
> After weeks of downloading and printing all the
> Microchip appnotes, and the F873 and 24LC256
> datasheets, with all been read at least once and
> handwritten notes through them, and I2C timing
> diagrams up on my wall, and downloading all the
> piclist.com I2C source code, and thinking I knew
> just about all the secrets to bit-banging I2C to a
> serial eeprom, well... It doesn't work.

<snip>

You did not say if you had more than one 24LC256 (me thinks) but of
coarse you have to re-address when crossing the boundry from one chip to
another.  Also, check that you are re-addressing when crossing the
internal buffer boundry.  I think the specs say that you can write 64
bytes at a time but I know for a fact that at least one i2c chip from
Microchip requires readdressing at addresses evenly divisable by 64 or
whatever the buffer size is--not 64 bytes starting at any address.  (The
specs did not reflect that fact but do now!)

I assume you are using the tristate bits to communicate.

Regards,
David Koski

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\07@195652 by Patrik Husfloen

picon face
I'm having the same problems, except I'm trying to interface a digital potentiometer but it's I2C and it's not working :(

What µP are you using? And what language?

Patrik

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\05\08@044403 by Roman Black

flavicon
face
Jerry Merrill wrote:
>
> Roman:
>
> I fought something like this once.  The problem ended up being related to
> R-M-W on the port pins.  Each time I toggled the CLOCK pin, it would latch
> the CURRENT state of the DATA pin (which of course can change when the
> slave ACKs.  The solution was to restore the DATA pin after each CLOCK
> change.  I suppose using shadow registers might of done it as well.
>
> My (CVASM) source for talking to a 24C00 type device is at:
>
> http://www.tech-tools.com
>
> Click on "search" and search for "i2c"


Thanks Jerry, this got me thinking. A quick check of my
code shows that it might be possible to get a RMW error,
and if this happens my PIC will be actively driving the
SDA line high so I may have damaged the eeprom.
I will re-code it tonight to remove any chances of
getting RMW problems. :o)

Thanks to everyone who offered help!! Many good suggestions
there. Thanks Olin for the 1k resistor tip, I always assume
a digital pin will pull 5mA low but the datasheet is very
sketchy with current data. It does mention 3mA, so I will
follow your advice and chnage the resistor to 2k2.

Thanks again everyone! :o)
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@083026 by Matt Sidare

flavicon
face
Roman,

You wrote:
"I have a 1k pullup resistor on SDA. Speed is 16MHz,
or 4MHz/inst."

Do you have/need a pull up on the clock line?

Matt

______________________
Matt Sidare
Software Engineer
Corning Tropel Corporation
60 O'Connor Road
Fairport, NY 14450
E-Mail: .....sidareKILLspamspam.....tropel.com
Phone: (716) 388-3496
Fax: (716) 388-3414
______________________

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@101651 by Roman Black

flavicon
face
Matt Sidare wrote:
>
> Roman,
>
> You wrote:
> "I have a 1k pullup resistor on SDA. Speed is 16MHz,
> or 4MHz/inst."
>
> Do you have/need a pull up on the clock line?

Hi Matt, thanks, but the Microchip serial eeproms
like 24LC256 work fine with a simple clock, ie
driven only by the master. All the Microchip
code examples etc do this. It's not a perfect
I2C protocol interface, i'm just trying to connect
a 24LC256 to a F873. I will stomp that RMW bug
tonight and see how it goes.
Thanks again to everyone who offered help. :o)
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@133419 by Roman Black

flavicon
face
I found my I2C eeprom problem and yes it was
embarassing!

My first mistake was a read-modify-write code
bug that could have allowed SDA to drive active
high into the eeprom's active low and fried one
or both chips. Very nasty, and after hours of
testing it with the bug I fully expected one
chip to have a fried pin.

However(!) I found a second mistake in my hardware
where i'm using a new protoboard and unlike my
old one this one has +5v and 0v rails that have to
be jumpered from the top half to the bottom half
of the board. I didn't see this so during all my
testing the eeprom (sheer luck) was on the unpowered
half of the board!

So my first mistake should have fried chips but my
second mistake made sure the entire eeprom was
totally floating compared to the PIC. Ha ha!! Who
said two wrongs don't make a right? I'm sure i'm
charmed sometimes. :o)

Thanks to everyone for your help!
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@134811 by Dal Wheeler

flavicon
face
Hehe, I've done that before too!  However, I ended up frying misc. opamps in
the process so maybe I'm not quite as charmed as you are.
{Original Message removed}

2001\05\08@135018 by Roman Black

flavicon
face
embedded engineer wrote:

> You did not say if you had more than one 24LC256 (me thinks) but of
> coarse you have to re-address when crossing the boundry from one chip to
> another.  Also, check that you are re-addressing when crossing the
> internal buffer boundry.  I think the specs say that you can write 64
> bytes at a time but I know for a fact that at least one i2c chip from
> Microchip requires readdressing at addresses evenly divisable by 64 or
> whatever the buffer size is--not 64 bytes starting at any address.  (The
> specs did not reflect that fact but do now!)
> Regards,
> David Koski


David, I am interested to lean more about this. I'm using the
new Microchip 24LC256 and have the latest datasheet.

Are you saying you must send a new address for each block
of 64 bytes?? The datasheet says that after a read ack the
eeprom increments the pointer to the next byte.
I assumed that to mean you can send address 00 00 and then
just sequentially read all 32768 bytes simply by acking
after each byte. ??

Are you sure you must re-address for each new block??
Thanks,
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@145033 by Andrew Warren

flavicon
face
Roman Black <EraseMEPICLISTspam_OUTspamTakeThisOuTmitvma.mit.edu> wrote:

> Are you saying you must send a new address for each block of 64
> bytes?? The datasheet says that after a read ack the eeprom
> increments the pointer to the next byte. I assumed that to mean you
> can send address 00 00 and then just sequentially read all 32768
> bytes simply by acking after each byte. ??

Roman:

You can READ all 32K bytes that way; David was talking about WRITING.

The EEPROM's page-write mode allows up to 64 bytes to be written at
once.  For instance, you can write 64 bytes from address 0 to 63 in
one operation, by writing address 0 followed by 64 bytes of data.

However, all the data you write must be on the same 64-byte-wide
page.  You can write 10 bytes from address 10 to 19, for example, but
if you try writing 10 bytes from address 60 to address 69, the
EEPROM's internal address pointer wraps around and you'll ACTUALLY
end up writing to 60 through 63 and 0 through 9.  To write to 60-69,
you have to send one address for 60-63 and another for 64-69.

-Andy


=== Andrew Warren --- aiwspamspam_OUTcypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@145519 by embedded engineer

flavicon
face
Roman Black wrote:
>
> David, I am interested to lean more about this. I'm using the
> new Microchip 24LC256 and have the latest datasheet.
>
> Are you saying you must send a new address for each block
> of 64 bytes?? The datasheet says that after a read ack the
> eeprom increments the pointer to the next byte.
> I assumed that to mean you can send address 00 00 and then
> just sequentially read all 32768 bytes simply by acking
> after each byte. ??
>
> Are you sure you must re-address for each new block??
> Thanks,
> -Roman

Perhaps it is my confusion.  I did not assume the error condition was
related to reading.  The 64 byte buffer is used for writing--probably
not an issue to you?  It has been a couple of years since I have done
I2C drivers (used in production units numbering in the thousands) but I
distinctly remember writing errors when for example writing 64 bytes
starting at 00 0f.  It was not the 24LC256 but--and this is my main
point--the specs did not document this behavior.  The specs only said
you could not write more than 64 (or buffer size) bytes in a row.

Regards,
David

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@174911 by Alexandre Domingos F. Souza

flavicon
face
>However(!) I found a second mistake in my hardware
>where i'm using a new protoboard and unlike my
>old one this one has +5v and 0v rails that have to
>be jumpered from the top half to the bottom half
>of the board. I didn't see this so during all my
>testing the eeprom (sheer luck) was on the unpowered
>half of the board!

       I had the same problem some months ago. I got a new 3M Protoboard (wow, the most beautiful I've ever seen!!!) and in the vcc/gnd sidebar, you have 2 sections for each line!!! And it's marked nowhere in the protoboard!!! The first thing I did was to connect all of them with jumpers. Problem solved forever.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\09@042844 by Roman Black

flavicon
face
Andrew Warren wrote:

> You can READ all 32K bytes that way; David was talking about WRITING.
>
> The EEPROM's page-write mode allows up to 64 bytes to be written at
> once.  For instance, you can write 64 bytes from address 0 to 63 in
> one operation, by writing address 0 followed by 64 bytes of data.
>
> However, all the data you write must be on the same 64-byte-wide
> page.  You can write 10 bytes from address 10 to 19, for example, but
> if you try writing 10 bytes from address 60 to address 69, the
> EEPROM's internal address pointer wraps around and you'll ACTUALLY
> end up writing to 60 through 63 and 0 through 9.  To write to 60-69,
> you have to send one address for 60-63 and another for 64-69.


Thanks Andy, that's fine and is how I understood it.
I'm only writing 4 bytes at a time (always re-addressed)
but did plan on reading the whole 32kbytes in one read.
:o)
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...