1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Problem with multiple I2C devices in a bus...

Discussion in 'Embedded' started by starfire, Feb 17, 2005.

  1. starfire

    starfire Guest

    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
     
    starfire, Feb 17, 2005
    #1
    1. Advertisements

  2. starfire

    Wil Taphoorn Guest

    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 Taphoorn, Feb 17, 2005
    #2
    1. Advertisements

  3. On Wednesday, in article
    <>
    Yes many times.
    Last time I used DS1803 I had four of them, plus several PCF8574 and PCF8591
    off a PCF8584 controller on a H8.
    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?
    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.
    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.
    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, Feb 17, 2005
    #3
  4. starfire

    starfire Guest

    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
     
    starfire, Feb 17, 2005
    #4
  5. starfire

    starfire Guest

    Thanks for the reply, Wil.

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

    Dave
     
    starfire, Feb 17, 2005
    #5
  6. starfire

    Stef Guest

    In comp.arch.embedded,
    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, Feb 17, 2005
    #6
  7. starfire

    starfire Guest

    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
     
    starfire, Feb 18, 2005
    #7
  8. On Thursday, in article <>

    In other setups I have used I2C down 9 feet of twisted pair + shield cable.
    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.
     
    Paul Carpenter, Feb 18, 2005
    #8
  9. starfire

    Wil Taphoorn Guest

    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 Taphoorn, Feb 18, 2005
    #9
  10. starfire

    starfire Guest

    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.
     
    starfire, Feb 18, 2005
    #10
  11. starfire

    starfire Guest

    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
     
    starfire, Feb 18, 2005
    #11
  12. Hi starfire,
    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!

    Michael
     
    Michael Lange, Feb 19, 2005
    #12
  13. starfire

    Wil Taphoorn Guest

    Please don't top post.
    Ok, I must have misread you then.
    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 Taphoorn, Feb 19, 2005
    #13
  14. On Friday, in article <>
    "starfire" wrote:
    As others have said please reply at the BOTTOM it is getting tiring
    re jigging your posts..
    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.
    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, Feb 19, 2005
    #14
  15. starfire

    starfire Guest


    .... 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
     
    starfire, Feb 19, 2005
    #15
  16. starfire

    starfire Guest

    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
     
    starfire, Feb 19, 2005
    #16
  17. On Saturday, in article <>
    "starfire" wrote:

    .....
    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.
    The package style is close enough to the SOIC 150ml (if not slightly larger)
    Actually the DS1803 is also available in 14pin TSSOP
    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, Feb 20, 2005
    #17
  18. starfire

    starfire Guest

    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
     
    starfire, Feb 20, 2005
    #18
  19. On Sunday, in article <>
    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.
    SOT23-5 are finer pitch 5 pin SOT23 devices (0.4mm pitch on one side),
    basically 5 pins on a SOT23.
    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, Feb 20, 2005
    #19
  20. starfire

    starfire Guest

    Thanks, Paul.

     
    starfire, Feb 20, 2005
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.