Hi all - Has anyone had any experience with using multiple I2C devices is a bus architecture? I am using a PIC18LF252 uC, a 24LC256 serial EEPROM, and three Dallas DS1803 dual 100K programmable pots in a bus. The circuit is on a printed circuit board (not wire-wrapped or breadboarded). The total length of SDA and SCL lines is about 3 inches. I'm using the CCS C compiler with built-in I2C functions for I2C start, stop, write, and read. I had to write my own routines to handle the DS1803 device specifics. I breadboarded a single DS1803 with some test code using the routines to verify correct operation. It seemed to work well. When I put the three DS1803 chips in the circuit, along with the memory chip though, it gives erratic results. I looked at the SDA and SCL on a logic analyzer and found out why it was erratic. Every other time I executed a read instruction, the SDA line stayed low (did not output the stop condition). The following command fails but resets the SDA line high again so the next instruction following works again. This repeats indefinitely. Every other read works. The write cycles seem to be OK so I thought it must be timing related. The DS1803 reads both pot values sequentially and I thought the data on the second read was being output too soon or something. I inserted small delays (about 10ms) between byte reads in the sequence. No help. I added a second stop after the first stop (thinking at least one would get through). That made matters worse. I've varied the size of the pullup resistors from 1.2K to 4.7K. No value made it work completely, although some values seemed to work a little better than others (around 2.0K to 2.2K worked the best). One DS1803 and the memory seem to work almost all the time while the other two DS1803s exhibit this toggling-read symptom. The daisy-chain for the bus goes from memory-to-PIC-to-DS1803A-to-DS1803B-to-DS1803C. DS1803B is the one working most of the time while A and C toggle. Does anyone have any idea what's happening or what I may not have considered? TIA Dave
Problem with multiple I2C devices in a bus...
Started by ●February 16, 2005
Reply by ●February 17, 20052005-02-17
starfire wrote:> > Every other time I executed a read instruction, the SDA line stayed low > (did not output the stop condition).Looks like the 'low' is the first next data bit output by the slave. Are you sure you NAK'ed on the last byte read? -- Wil
Reply by ●February 17, 20052005-02-17
On Wednesday, in article
<1117u2aiovrobdc@corp.supernews.com>
starfire151@cableone.net "starfire" wrote:
>Hi all -
>
>Has anyone had any experience with using multiple I2C devices is a bus
>architecture?
Yes many times.
>I am using a PIC18LF252 uC, a 24LC256 serial EEPROM, and three Dallas DS1803
>dual 100K programmable pots in a bus. The circuit is on a printed circuit
>board (not wire-wrapped or breadboarded). The total length of SDA and SCL
>lines is about 3 inches.
Last time I used DS1803 I had four of them, plus several PCF8574 and PCF8591
off a PCF8584 controller on a H8.
>I'm using the CCS C compiler with built-in I2C functions for I2C start,
>stop, write, and read. I had to write my own routines to handle the DS1803
>device specifics. I breadboarded a single DS1803 with some test code using
>the routines to verify correct operation. It seemed to work well. When I
>put the three DS1803 chips in the circuit, along with the memory chip
>though, it gives erratic results.
The DS1803 is not too difficult to write for. Are you sure you are putting
the correct addresses out for all devices. Single unit has base address
(0x50) however adding extra unit addresses tends to be where most people
screw up on creating I2C addresses.
What sub-addresses (unit numbers) are you using for the DS1803 devices?
>I looked at the SDA and SCL on a logic analyzer and found out why it was
>erratic. Every other time I executed a read instruction, the SDA line
>stayed low (did not output the stop condition). The following command fails
>but resets the SDA line high again so the next instruction following works
>again. This repeats indefinitely. Every other read works. The write
>cycles seem to be OK so I thought it must be timing related. The DS1803
>reads both pot values sequentially and I thought the data on the second read
>was being output too soon or something. I inserted small delays (about
>10ms) between byte reads in the sequence. No help. I added a second stop
>after the first stop (thinking at least one would get through). That made
>matters worse.
The first thing I would check is that your are addressing the devices
correctly as getting the addresses wrong in I2C causes a difference between
read and write mode.
Secondly I would check you are sending the correct command as DS1803
supports three different read/write methods pot 0, pot 1 or both pots
depending on the command sent after the address before reading/writing.
I only ever supported single pot read/write, because that was easier
to implement in the application it was for and made parameter passing
smaller.
>I've varied the size of the pullup resistors from 1.2K to 4.7K. No value
>made it work completely, although some values seemed to work a little better
>than others (around 2.0K to 2.2K worked the best). One DS1803 and the
>memory seem to work almost all the time while the other two DS1803s exhibit
>this toggling-read symptom. The daisy-chain for the bus goes from
>memory-to-PIC-to-DS1803A-to-DS1803B-to-DS1803C. DS1803B is the one working
>most of the time while A and C toggle.
The fact that the ones toggling are two addresses apart makes me more
suspicious of addressing fault. That makes me think your address is not
being shifted the correct number of bits.
>Does anyone have any idea what's happening or what I may not have
>considered?
I would start double checking the addressing and command sent first.
If you want <http://www.gnuh8.org.uk/files.htm> includes an I2C example
that has in it a DS1803 module in C that may help. Don't use the read/write
two pots in one command with that code, it won't work, but single pot
read/write will work. This has worked for 5 years on one product.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Reply by ●February 17, 20052005-02-17
Thanks for the reply, Paul. The addressing is correct for the three devices. I've checked it several times. The device addresses that are flaky are the 000 and 001. Address 010 seems to work fairly consistently. I've confirmed the addressing with the logic analyzer. I've downloaded the example you referred to from your web page and will examine it. I haven't had a chance to take a look at it yet. I will probably get a chance today or tomorrow. Thanks, again. Dave "Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message news:20050217.0937.306771snz@pcserv.demon.co.uk...> On Wednesday, in article > <1117u2aiovrobdc@corp.supernews.com> > starfire151@cableone.net "starfire" wrote: >>Hi all - >> >>Has anyone had any experience with using multiple I2C devices is a bus >>architecture? > > Yes many times. > >>I am using a PIC18LF252 uC, a 24LC256 serial EEPROM, and three Dallas >>DS1803 >>dual 100K programmable pots in a bus. The circuit is on a printed circuit >>board (not wire-wrapped or breadboarded). The total length of SDA and SCL >>lines is about 3 inches. > > Last time I used DS1803 I had four of them, plus several PCF8574 and > PCF8591 > off a PCF8584 controller on a H8. > >>I'm using the CCS C compiler with built-in I2C functions for I2C start, >>stop, write, and read. I had to write my own routines to handle the >>DS1803 >>device specifics. I breadboarded a single DS1803 with some test code >>using >>the routines to verify correct operation. It seemed to work well. When I >>put the three DS1803 chips in the circuit, along with the memory chip >>though, it gives erratic results. > > The DS1803 is not too difficult to write for. Are you sure you are putting > the correct addresses out for all devices. Single unit has base address > (0x50) however adding extra unit addresses tends to be where most people > screw up on creating I2C addresses. > > What sub-addresses (unit numbers) are you using for the DS1803 devices? > >>I looked at the SDA and SCL on a logic analyzer and found out why it was >>erratic. Every other time I executed a read instruction, the SDA line >>stayed low (did not output the stop condition). The following command >>fails >>but resets the SDA line high again so the next instruction following works >>again. This repeats indefinitely. Every other read works. The write >>cycles seem to be OK so I thought it must be timing related. The DS1803 >>reads both pot values sequentially and I thought the data on the second >>read >>was being output too soon or something. I inserted small delays (about >>10ms) between byte reads in the sequence. No help. I added a second stop >>after the first stop (thinking at least one would get through). That made >>matters worse. > > The first thing I would check is that your are addressing the devices > correctly as getting the addresses wrong in I2C causes a difference > between > read and write mode. > > Secondly I would check you are sending the correct command as DS1803 > supports three different read/write methods pot 0, pot 1 or both pots > depending on the command sent after the address before reading/writing. > > I only ever supported single pot read/write, because that was easier > to implement in the application it was for and made parameter passing > smaller. > >>I've varied the size of the pullup resistors from 1.2K to 4.7K. No value >>made it work completely, although some values seemed to work a little >>better >>than others (around 2.0K to 2.2K worked the best). One DS1803 and the >>memory seem to work almost all the time while the other two DS1803s >>exhibit >>this toggling-read symptom. The daisy-chain for the bus goes from >>memory-to-PIC-to-DS1803A-to-DS1803B-to-DS1803C. DS1803B is the one >>working >>most of the time while A and C toggle. > > The fact that the ones toggling are two addresses apart makes me more > suspicious of addressing fault. That makes me think your address is not > being shifted the correct number of bits. > >>Does anyone have any idea what's happening or what I may not have >>considered? > > I would start double checking the addressing and command sent first. > > If you want <http://www.gnuh8.org.uk/files.htm> includes an I2C example > that has in it a DS1803 module in C that may help. Don't use the > read/write > two pots in one command with that code, it won't work, but single pot > read/write will work. This has worked for 5 years on one product. > > -- > Paul Carpenter | paul@pcserviceselectronics.co.uk > <http://www.pcserviceselectronics.co.uk/> PC Services > <http://www.gnuh8.org.uk/> GNU H8 & mailing list info > <http://www.badweb.org.uk/> For those web sites you hate >
Reply by ●February 17, 20052005-02-17
Thanks for the reply, Wil. I will double check the logic analyzer output and look for the NAKs, again. Dave "Wil Taphoorn" <wil@nogo.wtms.nl> wrote in message news:42145B38.FC0FD276@nogo.wtms.nl...> starfire wrote: >> >> Every other time I executed a read instruction, the SDA line stayed low >> (did not output the stop condition). > > Looks like the 'low' is the first next data bit output by the slave. Are > you sure you NAK'ed on the last byte read? > > -- > Wil
Reply by ●February 17, 20052005-02-17
In comp.arch.embedded, starfire <starfire151@cableone.net> wrote:> >I looked at the SDA and SCL on a logic analyzer and found out why it was >erratic. Every other time I executed a read instruction, the SDA lineDid you also check the signals with a scope? The analyzer will only tell you when it thinks the lines are high and low, but gives you little information on the actual levels and rise- and falltimes. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) A good supervisor can step on your toes without messing up your shine.
Reply by ●February 17, 20052005-02-17
Yes, actually I used a 16-channel Logic Scope from Tektronix. It shows all the transitions on the lines like a scope but has a larger data capture buffer so you can scroll through the capture history to see all the transitions of the command. The problem seems to be related to the data line not being shut off (left to be pulled back up to +5V after a complete transmission). Dave "Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message news:77802$42150e3a$54f63171$21540@publishnet.news-service.com...> In comp.arch.embedded, > starfire <starfire151@cableone.net> wrote: >> >>I looked at the SDA and SCL on a logic analyzer and found out why it was >>erratic. Every other time I executed a read instruction, the SDA line > > Did you also check the signals with a scope? The analyzer will only tell > you when it thinks the lines are high and low, but gives you little > information on the actual levels and rise- and falltimes. > > -- > Stef (remove caps, dashes and .invalid from e-mail address to reply by > mail) > > A good supervisor can step on your toes without messing up your shine.
Reply by ●February 18, 20052005-02-18
On Thursday, in article <11195fvbv8h9l33@corp.supernews.com>
starfire151@cableone.net "starfire" wrote:
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20050217.0937.306771snz@pcserv.demon.co.uk...
>> On Wednesday, in article
>> <1117u2aiovrobdc@corp.supernews.com>
>> starfire151@cableone.net "starfire" wrote:
>>>Hi all -
>>>
>>>Has anyone had any experience with using multiple I2C devices is a bus
>>>architecture?
...
>>>I am using a PIC18LF252 uC, a 24LC256 serial EEPROM, and three Dallas
>>>DS1803
>>>dual 100K programmable pots in a bus. The circuit is on a printed circuit
>>>board (not wire-wrapped or breadboarded). The total length of SDA and SCL
>>>lines is about 3 inches.
>>
>> Last time I used DS1803 I had four of them, plus several PCF8574 and
>> PCF8591 off a PCF8584 controller on a H8.
In other setups I have used I2C down 9 feet of twisted pair + shield cable.
>>>I'm using the CCS C compiler with built-in I2C functions for I2C start,
>>>stop, write, and read. I had to write my own routines to handle the
>>>DS1803
>>>device specifics. I breadboarded a single DS1803 with some test code
>>>using
>>>the routines to verify correct operation. It seemed to work well. When I
>>>put the three DS1803 chips in the circuit, along with the memory chip
>>>though, it gives erratic results.
>>
>> The DS1803 is not too difficult to write for. Are you sure you are putting
>> the correct addresses out for all devices. Single unit has base address
>> (0x50) however adding extra unit addresses tends to be where most people
>> screw up on creating I2C addresses.
>>
>> What sub-addresses (unit numbers) are you using for the DS1803 devices?
>>
>>>I looked at the SDA and SCL on a logic analyzer and found out why it was
>>>erratic. Every other time I executed a read instruction, the SDA line
>>>stayed low (did not output the stop condition). The following command
>>>fails
>>>but resets the SDA line high again so the next instruction following works
>>>again. This repeats indefinitely. Every other read works. The write
>>>cycles seem to be OK so I thought it must be timing related. The DS1803
>>>reads both pot values sequentially and I thought the data on the second
>>>read
...
>> The first thing I would check is that your are addressing the devices
>> correctly as getting the addresses wrong in I2C causes a difference
>> between read and write mode.
...
>Thanks for the reply, Paul.
>
>The addressing is correct for the three devices. I've checked it several
>times. The device addresses that are flaky are the 000 and 001. Address
>010 seems to work fairly consistently. I've confirmed the addressing with
>the logic analyzer.
There is of course the other thing, you have checked that all three
address selection lines on ALL the DS1803 devices with a meter so that you
have not got a floating input causing one device to be recognised at
TWO addresses.
On your breadboard setup if it still exists can you test a single device
at the same addresses as your three device setup, to check the code for
multiple devices.
>I've downloaded the example you referred to from your web page and will
>examine it. I haven't had a chance to take a look at it yet. I will
>probably get a chance today or tomorrow.
>
>Thanks, again.
>
>Dave
>
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Reply by ●February 18, 20052005-02-18
starfire wrote:> The problem seems to be related to the data line not being shut off (left to > be pulled back up to +5V after a complete transmission).This differs from what you wrote the first time: | Every other time I executed a read instruction, the SDA line | stayed low (did not output the stop condition). If the line is high than the master can generate a STOP or any other condition. If the lien stays low (as you reported earlier) the the master can do nothing. -- Wil
Reply by ●February 18, 20052005-02-18
I don't think it differs from what I wrote earlier. The condition is consistent. When monitoring the SDA and SCL lines, the initial condition after power-up is that both lines are high (pulled up). When I execute any write instruction to any device on the bus, the final condition of the lines are left both high again. If I execute any read instruction to either the pot at address 000 or the pot at address 001, the read completes successfully (at least I see the data returned from the pots that was programmed into them) but the status of lines is left with the clock line high and the data line low. The next attempt at a read (or a write) fails because the start condition is not sent on the bus. At the end of the that instruction, though, the data line is high again so the following instruction is executed correctly again. Reads to the pot at address 010 were OK and left the data line high. I'm sorry if I wasn't clear in my original posting. Dave BTW: As an interesting note, I had to complete the population of the remainder of the components on the board so the remainder of the testing could continue. The pots were in the circuits of the other components as resistor elements only. The problem identified above continued but the two failing pots are at addresses 001 and 010 now. The pot at address 000 seems to work OK now. Wierd. "Wil Taphoorn" <wil@nogo.wtms.nl> wrote in message news:4215EC59.764798ED@nogo.wtms.nl...> starfire wrote: > >> The problem seems to be related to the data line not being shut off (left >> to >> be pulled back up to +5V after a complete transmission). > > This differs from what you wrote the first time: > | Every other time I executed a read instruction, the SDA line > | stayed low (did not output the stop condition). > > If the line is high than the master can generate a STOP or any > other condition. If the lien stays low (as you reported earlier) > the the master can do nothing. > > -- > Wil
