Problem with multiple I2C devices in a bus...

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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



Re: Problem with multiple I2C devices in a bus...
Quoted text here. Click to load it

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

Re: Problem with multiple I2C devices in a bus...
Thanks for the reply, Wil.

I will double check the logic analyzer output and look for the NAKs, again.

Dave

Quoted text here. Click to load it



Re: Problem with multiple I2C devices in a bus...
On Wednesday, in article
Quoted text here. Click to load it

Yes many times.

Quoted text here. Click to load it

Last time I used DS1803 I had four of them, plus several PCF8574 and PCF8591
off a PCF8584 controller on a H8.

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem with multiple I2C devices in a bus...
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

Quoted text here. Click to load it



Re: Problem with multiple I2C devices in a bus...
Quoted text here. Click to load it
...

In other setups I have used I2C down 9 feet of twisted pair + shield cable.

Quoted text here. Click to load it
...
...


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.

Quoted text here. Click to load it

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem with multiple I2C devices in a bus...
Thanks for the reply again, Paul.

The address lines are hard-wired circuit traces.  I have confirmed correct
addressing on all three of them.

BTW, are you aware (or have any experience with) any SOIC, dual channel, I2C
programmable pots with non-volatile memory?  These Dallas devices are OK but
they lose programming on power-down and I need to restore their values from
PIC EEPROM on power-up.

Thanks.

Dave


Quoted text here. Click to load it



Re: Problem with multiple I2C devices in a bus...
As others have said please reply at the BOTTOM it is getting tiring
re jigging your posts..
Quoted text here. Click to load it
....
....
...


My issue was not the traces, but the quality of connections and shorts.
Have you checked your code against the breadboard with the breadboard
device at 000, 001 and 010.

Quoted text here. Click to load it

In my application EEPROM was no use as the power unit had to reset, and a
startup sequence was needed, a saved value would set the wrong mode and smoke.
Without looking too hard I know that Dallas (now Maxim) and Xicor (now
Intersil) do parts with EEPROM.

A google search for "+EEPROM =pot" or "E2Pot" will turn up a lot of results.
  
The fact that Dallas/Maxim do parts with EEPROM and you had not found that
out worries me to how well you are looking at the problem as myself and others
have pointed out several items to check.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem with multiple I2C devices in a bus...

Quoted text here. Click to load it

...snip...


Paul -

Thanks for the resposne, again.

I have been trying everything that everyone has suggested to check.  That's
how I ultimately found the answer (due to the no ack on the last read) to
the problem.

I have checked Dallas/Maxim and Xicor for EEPROM pot parts but they don't
make such parts with multiple addresses, dual devices, EEPROM, and I2C in an
SOIC package, as was my original request.  I have also checked into the
Xicor parts.  Ditto.

I have, in fact, done complete parametric searches on the Dallas/Maxim,
Microchip, and Xicor sites.

The closest I've found is the Maxim MAX5479, which is in a different package
style.  I'm putting my circuits together by hand (without using reflow
ovens, etc.) so my package styles are necessarily somewhat limited.  I can't
do ball grid arrays, for instance.

Thanks for the help.

Dave



Re: Problem with multiple I2C devices in a bus...

....
Quoted text here. Click to load it
...

But it depends on what you mean by SOIC, as there are 150mil and 300mil
variants.

Most 14-20 pin TSSOP (173mil) packages are similar to SOIC 150mil.
 
Quoted text here. Click to load it


The package style is close enough to the SOIC 150ml (if not slightly larger)
Actually the DS1803 is also available in 14pin TSSOP
 
Quoted text here. Click to load it

I do lots of boards by hand with SOT23-5 and even 144pin TQFP on 0.4mm pitch.
The TSSOP is slightly larger so probably easier to hand solder, also the pin
out probably makes isolation between load and micro easier.

You just have to be careful and an iron which can go don to 0.2mm tip helps
on reworking as well.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem with multiple I2C devices in a bus...

Quoted text here. Click to load it

...snip...


Actually, I've done connectors at 0.5mm pitch, also.  The tip of my standard
Weller looked huge compared to the leads of the connector but being very
careful, I managed to be successful.  That was only 16 pins.  I don't think
I would attempt anything like a large flat pack without a much finer tip on
my iron.  I've done a ton of SOT23 devices.  They're not a problem.

Have you found any way of doing BGAs by hand or is it flat impractical?

Dave



Re: Problem with multiple I2C devices in a bus...

Quoted text here. Click to load it
...snip...


I use a Weller with 0.8mm tip and a JBC iron with interchangeable tips down
to conical 0.2mm. Also the JBC has temperature control and keeps the iron at
half temperature when the iron is on the stand, and heats to full temperature
in 2 seconds.

I find Elctrobe Flux pens useful for hand assembly/rework.

Quoted text here. Click to load it

SOT23-5 are finer pitch 5 pin SOT23 devices (0.4mm pitch on one side),
basically 5 pins on a SOT23.

Quoted text here. Click to load it

Impractical to do any BGA by hand as you cannot check the joints properly
or be sure you you enough solder/flux on all pads to the same amount.
They need good reflow ovens to heat board and device at the same time.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem with multiple I2C devices in a bus...
Thanks, Paul.

Quoted text here. Click to load it



Re: Problem with multiple I2C devices in a bus...
In comp.arch.embedded,
Quoted text here. Click to load it

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.

Re: Problem with multiple I2C devices in a bus...
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

Quoted text here. Click to load it



Re: Problem with multiple I2C devices in a bus...
 
Quoted text here. Click to load it

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

Re: Problem with multiple I2C devices in a bus...
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.


Quoted text here. Click to load it



Re: Problem with multiple I2C devices in a bus...
Hi starfire,

Quoted text here. Click to load it

That looks like my problem while expand some existing code, a few weeks
ago. Are you sure, the master send a NAK after the last byte, he would
read from the slave!? Otherwise, the next read/write operation to an
other device will be impaired by _this_ slave. He is always in read mode!
In short: End Read Mode by sending NAK from the master!

Quoted text here. Click to load it


Michael
--
Die eMail passt, und wer nicht spamt, kommt auch durch.
Gelesen wird jedoch nur ab und zu.


Re: Problem with multiple I2C devices in a bus...
Please don't top post.

Quoted text here. Click to load it

Ok, I must have misread you then.

Quoted text here. Click to load it
...

Did you verify that the driver does a NAK on the final byte of that read? I
suggested you to check that in my initial reply.

If the master does ACK on the final byte then the slave reacts by putting it
first bit of a new data byte onto the SDA line. If that bit happens to be 0
then the master is unable to reclaim the bus. If, however, the master does a
NAK on the final byte the slave will close, thereby releasing both SDA and SCL.

--
Wil

Re: Problem with multiple I2C devices in a bus...

Quoted text here. Click to load it


... snip ...



I just wanted to let everyone know I found the error of my ways.



The CCS compiler's i2c_read() instruction defaults to an acknowledge after
each read request.  The Dallas DS1803 states it should receive no
acknowledge on the last read data transfer.  There is a switch option in the
CCS read instruction to force a "no ack" after the read, which I coded after
the first read request.  Since the DS1803 did not see the "no ack"
condition, it must have been fooled into thinking there would be another
read request to follow.  The following command sends a bogus read request to
an invalid address, resulting in a "no ack", which apparently satisfies the
completion of the DS1803 cycle and it's ready for the next cycle.



I tried it again by forcing the ack after the first read and the no ack
after the second read.  It worked perfectly.



Much thanks for all the responses.  You were all instrumental in helping to
resolve this problem.  Once again this newsgroup has shown itself to be one
of the most knowledgeable and responsive newsgroups on the net.



Thanks.



Dave









Site Timeline