i2c communication

hello you all

i've been working on an i2c communication among a unique master and
several slaves...
(the source code i based on were the microchip application notes 734
and 735)
The first thing i need to do in my application is verifying the
presence of the slaves and a problem has rised: once the master sends
an address that produces a NOT acknowledge, no other slave responds to
the next call even though the address is correct...
the source code  has a routine to handle acknowledge errors, so that
such routine sets the bus free when a NOT acknowledge is received
(AN735)

PDD   the application has been simulated in proteus6

does anybody have any idea of what i could be doing wrong?

thanks for your help

juan schrieb in Nachricht
<96364396.0410221335.59296de7@posting.google.com>...
>hello you all
>
>i've been working on an i2c communication among a unique master and
>several slaves...
>(the source code i based on were the microchip application notes 734
>and 735)
>The first thing i need to do in my application is verifying the
>presence of the slaves and a problem has rised: once the master sends
>an address that produces a NOT acknowledge, no other slave responds to
>the next call even though the address is correct...
>the source code  has a routine to handle acknowledge errors, so that
>such routine sets the bus free when a NOT acknowledge is received
>(AN735)
>
>PDD   the application has been simulated in proteus6
>
>does anybody have any idea of what i could be doing wrong?

- Make a scope probe to find whats the bus is doing in the last state.
- Send a STOP on the bus after the NAK should fix it.
- Another possibility is to make a "bus reset" as described somewhere in a
Philips AppNote.
(The behavoir of some bus slaves is maybe not within the Philips i2c spec
and locks the bus)

regards -
Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
brasilianischer Sauerklee, Natron zum Backen/Baden, u.a.>
<Alternativ &#4294967295;ber http://people.freenet.de/algenkocher>

"juan" <facuadros@yahoo.es> schrieb im Newsbeitrag 
news:96364396.0410221335.59296de7@posting.google.com...
> The first thing i need to do in my application is verifying the
> presence of the slaves and a problem has rised: once the master sends
> an address that produces a NOT acknowledge, no other slave responds to
> the next call even though the address is correct...

Are you sure you send a stop condition after the NACK? It appears that your 
slaves are not ready to respond to the address.


> the source code  has a routine to handle acknowledge errors, so that
> such routine sets the bus free when a NOT acknowledge is received

What does that mean exactly? Sending a stop condition?

> does anybody have any idea of what i could be doing wrong?


You should check if both the clock and the data line are high wen attempting 
to address one of your slaves after you received the NACK.

I don't know the slave devices you are using but I know cases where confused 
slaves hold down the SCL line or even the SDA line :-( if their state 
machine is messed up.
Since the I2C bus - in contrast to the SMBus does not define any timeouts 
the only way to synchronize is to move the clock several times. However in 
your case it looks more like a missing stop condition.

/Roland

In article <96364396.0410221335.59296de7@posting.google.com>, 
facuadros@yahoo.es says...
> hello you all
> 
> i've been working on an i2c communication among a unique master and
> several slaves...
> (the source code i based on were the microchip application notes 734
> and 735)
> The first thing i need to do in my application is verifying the
> presence of the slaves and a problem has rised: once the master sends
> an address that produces a NOT acknowledge, no other slave responds to
> the next call even though the address is correct...
> the source code  has a routine to handle acknowledge errors, so that
> such routine sets the bus free when a NOT acknowledge is received
> (AN735)
> 
> PDD   the application has been simulated in proteus6
> 
> does anybody have any idea of what i could be doing wrong?
> 
> thanks for your help
> 
You can try doing the following :
Pull the data and clock both low (active) for 10ms.
Release them and wait 10ms.
Goto the next address.

I don't know if that is an "Official" bus reset or not,
but I remember having to do that with some EEPROMs once.

>You can try doing the following :
>Pull the data and clock both low (active) for 10ms.
>Release them and wait 10ms.
>Goto the next address.
>
>I don't know if that is an "Official" bus reset or not,
>but I remember having to do that with some EEPROMs once.
That might functions if you run it on SMBus (a newer variant of i2c for PC
hardware).
But definitely it will not work on i2c! There doesn't exists an time-out in
the spec.
Timing is not a great issue with i2c. What counts is where a edge on SCL
oder SDA comes in relation to logic states (on bus and inside the state
machines).

regards -
Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
brasilianischer Sauerklee, Natron zum Backen/Baden, u.a.>
<Alternativ &#4294967295;ber http://people.freenet.de/algenkocher>

"Henry Kiefer" <otc@gmx.net> wrote in message news:<2tusp2F1vhofkU1@uni-berlin.de>...
> 
> - Make a scope probe to find whats the bus is doing in the last state.
> - Send a STOP on the bus after the NAK should fix it.
> - Another possibility is to make a "bus reset" as described somewhere in a
> Philips AppNote.
> (The behavoir of some bus slaves is maybe not within the Philips i2c spec
> and locks the bus)
> 
> regards -
> Henry

thank you very much for your help...

the problem with the verification of slaves has been finaly solved:
as I could not find the literarature regarding the "bus reset" i tried
something that worked out:
in the main cycle of the slave program the sspbuf is read (in each
cycle) if such slave is not in the middle of a communication... in
this way it is sure
that when the master calls it its sspbuf register will be clear and
ready to answer

but another problem has rised:

when working with a slave as transmitter, after setting sspcon2.RCEN,
the SDA line is supposed to get the value of the most significant bit
contained in SSPBUF and then shifting out the next bits with the 
falling edges of the SCL line (so that the second bit of the byte to 
be transmitted is shifted out with the falling edge of the first 
clock pulse, the third bit with the second falling edge... and so on),
but what happens in my case is that the first bit shifted out is not 
the MSB (bit 7), but the next (i.e. the sixth). With this, data like 
10000000 is received by the master as 0 because the first bit shifted 
out is a 0 (bit 6) and both, the first and second clock pulses read 0;
and data like 01000000 is received as 11000000 because with the first 
and second clock pulses a 1 is read. Using a scope probe to view the 
state of the SDA & SCL lines -simulation in proteus 6- i saw that the
first change in the bits to be shifted out is not happening at the 
first falling edge of SCL but in the second.... 

I have been thinking and i see no reason for this to happen, and i 
was wondering if it was possible that the error is being caused by
the environment (proteus 6), not by the source code. And if it is 
not so, what could i be doing wrong?

Again, thank you very much

juan wrote:
> "Henry Kiefer" <otc@gmx.net> wrote in message news:<2tusp2F1vhofkU1@uni-berlin.de>...
> 
>>- Make a scope probe to find whats the bus is doing in the last state.
>>- Send a STOP on the bus after the NAK should fix it.
>>- Another possibility is to make a "bus reset" as described somewhere in a
>>Philips AppNote.
>>(The behavoir of some bus slaves is maybe not within the Philips i2c spec
>>and locks the bus)
>>
>>regards -
>>Henry
> 
> 
> thank you very much for your help...
> 
> the problem with the verification of slaves has been finaly solved:
> as I could not find the literarature regarding the "bus reset" i tried
> something that worked out:
> in the main cycle of the slave program the sspbuf is read (in each
> cycle) if such slave is not in the middle of a communication... in
> this way it is sure
> that when the master calls it its sspbuf register will be clear and
> ready to answer
> 
> but another problem has rised:
> 
> when working with a slave as transmitter, after setting sspcon2.RCEN,
> the SDA line is supposed to get the value of the most significant bit
> contained in SSPBUF and then shifting out the next bits with the 
> falling edges of the SCL line (so that the second bit of the byte to 
> be transmitted is shifted out with the falling edge of the first 
> clock pulse, the third bit with the second falling edge... and so on),
> but what happens in my case is that the first bit shifted out is not 
> the MSB (bit 7), but the next (i.e. the sixth). With this, data like 
> 10000000 is received by the master as 0 because the first bit shifted 
> out is a 0 (bit 6) and both, the first and second clock pulses read 0;
> and data like 01000000 is received as 11000000 because with the first 
> and second clock pulses a 1 is read. Using a scope probe to view the 
> state of the SDA & SCL lines -simulation in proteus 6- i saw that the
> first change in the bits to be shifted out is not happening at the 
> first falling edge of SCL but in the second.... 
> 
> I have been thinking and i see no reason for this to happen, and i 
> was wondering if it was possible that the error is being caused by
> the environment (proteus 6), not by the source code. And if it is 
> not so, what could i be doing wrong?
> 
> Again, thank you very much

Usually, there are two control bits for the clock: polarity and phase.
Check (against the spec sheets) that both are correctly set for your
hardware.

HTH

Tauno Voipio
tauno voipio (at) iki fi

>Timing is not a great issue with i2c. What counts is where a edge on SCL
>oder SDA comes in relation to logic states (on bus and inside the state
>machines).
Sorry! Read "oder" as "or" - it's german.

- Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
brasilianischer Sauerklee, Natron zum Backen/Baden, u.a.>
<Alternativ &#4294967295;ber http://people.freenet.de/algenkocher>

>I have been thinking and i see no reason for this to happen, and i
>was wondering if it was possible that the error is being caused by
>the environment (proteus 6), not by the source code. And if it is
>not so, what could i be doing wrong?
I don't think that Proteus is enough evolved to say it is virtually bugless.
Please try first Taunos' hint.

- Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
brasilianischer Sauerklee, Natron zum Backen/Baden, u.a.>
<Alternativ &#4294967295;ber http://people.freenet.de/algenkocher>

On Sat, 23 Oct 2004 14:01:59 +0200, "Roland Zitzke"
<FODVRUTMSTJC@spammotel.com> wrote:
>I2C bus <a lot of snip>

Just download the free specs of I2C from the Philips website.

Pieter Hoeben
http://www.hoeben.com