Problem with multiple I2C devices in a bus...

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?

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 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.

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

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

Thanks for the reply, Wil.

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

Dave

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.

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

...

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.

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.

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.

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

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

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.

On Friday, in article snipped-for-privacy@cableone.net "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.

... 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

...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

....

...

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.

...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

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.

Thanks, Paul.