Jon Kirwan wrote:
> On Tue, 15 Jun 2010 16:23:57 -0700, Jg wrote:
>
>> Now don't hit me, but did you ground the WP pin?
>
> If it is left floating, it's tied internally towards ground I
> think. But yes. I haven't used these parts and have never
> tried to operate a part that was externally write protected.
> I wonder if they even 'acknowledge' a write, if they are
> protected. Do you know one way or the other? I'm curious,
> now.
>
Don't know, I try to avoid I2C because of weird hang-up problems that I
have seen too often in existing designs. I prefer SPI. But the internal
pull-down is often more or less just capacitive, easy to upset. I
wouldn't trust that.
[...]
--
Regards, Joerg
http://www.analogconsultants.com/
Corruption on reading from EEPROM
Started by ●June 15, 2010
Reply by ●June 16, 20102010-06-16
Reply by ●June 16, 20102010-06-16
merapcb wrote:
> My clock is 300KHz which is within the rated speed of up to 1MHz for this part. And yes, WS is tied to ground...
> And yes, I can see the ACK after each group of 8 bits.
> :-(
>
I believe 300kHz requires the supply voltage to at least be around 3V.
Maybe probe that and see that there aren't any dips on VCC.
Can you slow it down and see if it works then?
Of course, there is also a chance that you might have gotten a shipment
of bad chips. Sometimes it helps to order a few from someone else,
hoping those are from another date code. The only other problem I could
imagine is timing errors but since you seem to use the canned I2C
routines that is unlikely.
--
Regards, Joerg
http://www.analogconsultants.com/
> My clock is 300KHz which is within the rated speed of up to 1MHz for this part. And yes, WS is tied to ground...
> And yes, I can see the ACK after each group of 8 bits.
> :-(
>
I believe 300kHz requires the supply voltage to at least be around 3V.
Maybe probe that and see that there aren't any dips on VCC.
Can you slow it down and see if it works then?
Of course, there is also a chance that you might have gotten a shipment
of bad chips. Sometimes it helps to order a few from someone else,
hoping those are from another date code. The only other problem I could
imagine is timing errors but since you seem to use the canned I2C
routines that is unlikely.
--
Regards, Joerg
http://www.analogconsultants.com/
Reply by ●June 16, 20102010-06-16
If the RTC is working and the EEPROM not then it is likely you have a
command or address error when building the data to send to the EEPROM.
Often this kind of error is so obvious that we cannot see in the code.
Since I am not a C programmer reading your code would take hours.
If what you see in the logic analyser is what your I2C interface
gives you then the I2C itself is ok.
So, I would say it is not a case of data corruption but just a
mistake in the usage of the EEPROM.
-Augusto
.
.
On Qua 16/06/10 11:50 , Joerg j...@analogconsultants.com sent:
merapcb wrote:
> My clock is 300KHz which is within the rated speed of up to 1MHz
for this part. And yes, WS is tied to ground...
> And yes, I can see the ACK after each group of 8 bits.
> :-(
>
I believe 300kHz requires the supply voltage to at least be around
3V.
Maybe probe that and see that there aren't any dips on VCC.
Can you slow it down and see if it works then?
Of course, there is also a chance that you might have gotten a
shipment
of bad chips. Sometimes it helps to order a few from someone else,
hoping those are from another date code. The only other problem I
could
imagine is timing errors but since you seem to use the canned I2C
routines that is unlikely.
--
Regards, Joerg
http://www.analogconsultants.com/ [1]
command or address error when building the data to send to the EEPROM.
Often this kind of error is so obvious that we cannot see in the code.
Since I am not a C programmer reading your code would take hours.
If what you see in the logic analyser is what your I2C interface
gives you then the I2C itself is ok.
So, I would say it is not a case of data corruption but just a
mistake in the usage of the EEPROM.
-Augusto
.
.
On Qua 16/06/10 11:50 , Joerg j...@analogconsultants.com sent:
merapcb wrote:
> My clock is 300KHz which is within the rated speed of up to 1MHz
for this part. And yes, WS is tied to ground...
> And yes, I can see the ACK after each group of 8 bits.
> :-(
>
I believe 300kHz requires the supply voltage to at least be around
3V.
Maybe probe that and see that there aren't any dips on VCC.
Can you slow it down and see if it works then?
Of course, there is also a chance that you might have gotten a
shipment
of bad chips. Sometimes it helps to order a few from someone else,
hoping those are from another date code. The only other problem I
could
imagine is timing errors but since you seem to use the canned I2C
routines that is unlikely.
--
Regards, Joerg
http://www.analogconsultants.com/ [1]
Reply by ●June 16, 20102010-06-16
--- In m..., Augusto Einsfeldt wrote:
>
> So, I would say it is not a case of data corruption but just a
> mistake in the usage of the EEPROM.
> -Augusto
> .
> .
How can it be a mistake in the use of the EEPROM if the Write operation is OK and all the Start/Stop/ACKs are seen on the Logic Analyzer?
>
> So, I would say it is not a case of data corruption but just a
> mistake in the usage of the EEPROM.
> -Augusto
> .
> .
How can it be a mistake in the use of the EEPROM if the Write operation is OK and all the Start/Stop/ACKs are seen on the Logic Analyzer?
Reply by ●June 16, 20102010-06-16
merapcb wrote:
>
> --- In m..., Augusto Einsfeldt wrote:
>
>> So, I would say it is not a case of data corruption but just a
>> mistake in the usage of the EEPROM.
>> -Augusto
>> .
>> .
>
> How can it be a mistake in the use of the EEPROM if the Write operation is OK and all the Start/Stop/ACKs are seen on the Logic Analyzer?
>
Have you tried looking at data and clock with an oscilloscope instead of
the logic analyzer?
--
Regards, Joerg
http://www.analogconsultants.com/
>
> --- In m..., Augusto Einsfeldt wrote:
>
>> So, I would say it is not a case of data corruption but just a
>> mistake in the usage of the EEPROM.
>> -Augusto
>> .
>> .
>
> How can it be a mistake in the use of the EEPROM if the Write operation is OK and all the Start/Stop/ACKs are seen on the Logic Analyzer?
>
Have you tried looking at data and clock with an oscilloscope instead of
the logic analyzer?
--
Regards, Joerg
http://www.analogconsultants.com/
Reply by ●June 16, 20102010-06-16
--- In m..., Joerg wrote:
> > Have you tried looking at data and clock with an oscilloscope instead of
> the logic analyzer?
>
> --
Sorry, no I have not (I don't have that type of scope). Why would it be different? (or how?)
> > Have you tried looking at data and clock with an oscilloscope instead of
> the logic analyzer?
>
> --
Sorry, no I have not (I don't have that type of scope). Why would it be different? (or how?)
Reply by ●June 16, 20102010-06-16
How can you know you wrote something if you cannot read it?
maybe your read opperation is working but not the write, no matter
if the I2C signaling is ok.
For instance, you have the R/W bit to check. also, when reading it
allways read the next address the you have written before. It is why
they suggest to do a dummy write to set the address pointer in order
to read the position you want.
Maybe you are just reading the next byte instead of the one you
wrote, and the erased state (factory) of an EEPROM doesn't need to be
0xFF.
-augusto
.
.
On Qua 16/06/10 12:50 , "merapcb" m...@yahoo.co.in sent:
--- In m..., Joerg wrote:
> >
>
> Have you tried looking at data and clock with an oscilloscope
instead of
> the logic analyzer?
>
> --
Sorry, no I have not (I don't have that type of scope). Why would it
be different? (or how?)
maybe your read opperation is working but not the write, no matter
if the I2C signaling is ok.
For instance, you have the R/W bit to check. also, when reading it
allways read the next address the you have written before. It is why
they suggest to do a dummy write to set the address pointer in order
to read the position you want.
Maybe you are just reading the next byte instead of the one you
wrote, and the erased state (factory) of an EEPROM doesn't need to be
0xFF.
-augusto
.
.
On Qua 16/06/10 12:50 , "merapcb" m...@yahoo.co.in sent:
--- In m..., Joerg wrote:
> >
>
> Have you tried looking at data and clock with an oscilloscope
instead of
> the logic analyzer?
>
> --
Sorry, no I have not (I don't have that type of scope). Why would it
be different? (or how?)
Reply by ●June 16, 20102010-06-16
On Wed, 16 Jun 2010 07:45:15 -0700, you wrote:
>Jon Kirwan wrote:
>> On Tue, 15 Jun 2010 16:23:57 -0700, Jg wrote:
>>
>>> Now don't hit me, but did you ground the WP pin?
>>
>> If it is left floating, it's tied internally towards ground I
>> think. But yes. I haven't used these parts and have never
>> tried to operate a part that was externally write protected.
>> I wonder if they even 'acknowledge' a write, if they are
>> protected. Do you know one way or the other? I'm curious,
>> now.
>
> Don't know, I try to avoid I2C because of weird hang-up
> problems that I have seen too often in existing designs.
I have done I2C with eeproms quite a few times and never had
a single problem to track down. Even the first time I tried
it. They have all simply worked and they are all still in
production, I believe, too. I haven't experienced a hang up
with anything where I wrote the bit-bang code. I'm not
saying my code is something to write home about or that my
hardware design is, either. I'm just saying that my modest
experience leaves me curious.
> I prefer SPI.
93LC46A comes immediately to mind, as I recently completed a
new contract to update a five year old project that used one
of those. Didn't need to change that code I'd written
before, but had to at least glance at it again.
Sufficient pins allowing, SPI is easy to use and understand.
74164-ish. And pin directions don't need to change on the
fly, so if you don't have that ability bit banged I2C should
be avoided.
Still, I haven't experienced the hang-up on I2C. I'm not
recommending one over another, as that depends on the case,
but just noting that I2C isn't hard to get right regarding
the software.
> But the internal pull-down is often more
> or less just capacitive, easy to upset. I wouldn't trust
> that.
That chip spec'd capacitive coupling to the board, memory
serving, of under 3pF, I think? Your question should have
been asked and your concern here is, of course, well placed.
...
I am curious what merapcb finds in the end. Assuming only
basic skills at hardware and software, it's hard to mess up.
The only thing I can imagine is that merapcb is misreading
something in the docs and not implementing the software
correctly because of that or merapcb has more fundamental
software writing problems to deal with.
Jon
>Jon Kirwan wrote:
>> On Tue, 15 Jun 2010 16:23:57 -0700, Jg wrote:
>>
>>> Now don't hit me, but did you ground the WP pin?
>>
>> If it is left floating, it's tied internally towards ground I
>> think. But yes. I haven't used these parts and have never
>> tried to operate a part that was externally write protected.
>> I wonder if they even 'acknowledge' a write, if they are
>> protected. Do you know one way or the other? I'm curious,
>> now.
>
> Don't know, I try to avoid I2C because of weird hang-up
> problems that I have seen too often in existing designs.
I have done I2C with eeproms quite a few times and never had
a single problem to track down. Even the first time I tried
it. They have all simply worked and they are all still in
production, I believe, too. I haven't experienced a hang up
with anything where I wrote the bit-bang code. I'm not
saying my code is something to write home about or that my
hardware design is, either. I'm just saying that my modest
experience leaves me curious.
> I prefer SPI.
93LC46A comes immediately to mind, as I recently completed a
new contract to update a five year old project that used one
of those. Didn't need to change that code I'd written
before, but had to at least glance at it again.
Sufficient pins allowing, SPI is easy to use and understand.
74164-ish. And pin directions don't need to change on the
fly, so if you don't have that ability bit banged I2C should
be avoided.
Still, I haven't experienced the hang-up on I2C. I'm not
recommending one over another, as that depends on the case,
but just noting that I2C isn't hard to get right regarding
the software.
> But the internal pull-down is often more
> or less just capacitive, easy to upset. I wouldn't trust
> that.
That chip spec'd capacitive coupling to the board, memory
serving, of under 3pF, I think? Your question should have
been asked and your concern here is, of course, well placed.
...
I am curious what merapcb finds in the end. Assuming only
basic skills at hardware and software, it's hard to mess up.
The only thing I can imagine is that merapcb is misreading
something in the docs and not implementing the software
correctly because of that or merapcb has more fundamental
software writing problems to deal with.
Jon
Reply by ●June 16, 20102010-06-16
On Wed, 16 Jun 2010 07:50:01 -0700, Jg wrote:
>I believe 300kHz requires the supply voltage to at least be around 3V.
>Maybe probe that and see that there aren't any dips on VCC.
>
>Can you slow it down and see if it works then?
There are setup and hold times involved, obviously, so this
may be a very helpful test to try. Cut it by a factor of 10
and try again.
Jon
>I believe 300kHz requires the supply voltage to at least be around 3V.
>Maybe probe that and see that there aren't any dips on VCC.
>
>Can you slow it down and see if it works then?
There are setup and hold times involved, obviously, so this
may be a very helpful test to try. Cut it by a factor of 10
and try again.
Jon
Reply by ●June 16, 20102010-06-16
Jon Kirwan wrote:
[...]
> I am curious what merapcb finds in the end. Assuming only
> basic skills at hardware and software, it's hard to mess up.
>
> The only thing I can imagine is that merapcb is misreading
> something in the docs and not implementing the software
> correctly because of that or merapcb has more fundamental
> software writing problems to deal with.
>
Or bad chips. BTW, the hang-ups I saw in I2C were not caused by
sub-optimal code but by devices inexplicably hogging the bus and never
letting go. The worst one required a power cycle to snap out of it.
--
Regards, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
[...]
> I am curious what merapcb finds in the end. Assuming only
> basic skills at hardware and software, it's hard to mess up.
>
> The only thing I can imagine is that merapcb is misreading
> something in the docs and not implementing the software
> correctly because of that or merapcb has more fundamental
> software writing problems to deal with.
>
Or bad chips. BTW, the hang-ups I saw in I2C were not caused by
sub-optimal code but by devices inexplicably hogging the bus and never
letting go. The worst one required a power cycle to snap out of it.
--
Regards, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
