I2C issues

[Amoque]

I originally posted here; then, thinking the issue was solved, moved on. Unfortunately, fate is not so kind and again I face the issue...

When the I2C Clock is connected to my 16F887A it works perfectly. When the port expander, PCF8574, occupies the bus, it too performs as expected... Either, individually, no issue. Together, the clock displays 04:04, 04/04/04... disconnect the PCF and presto... the clock displays correct time and date. Originally, I attributed this to power issues and - temporarily - resolved it by removing the clock backup battery but, as I've begun to experiment with a 3RD I2C on the buss - the problem has recurred.

The bus wires are no more than 12 inches and 24 gauge wire soldered (neat, clean, no residue) to perf board of Radio Shack quality. I've tried I2C resistors from 1K8 to 10K and it makes no difference. I've checked and rechecked everything I can think of and moved between clock modules (2 suppliers) and a socketed chip without effect. The problem is consistent... 04:04 - not random at all - regardless...

I thought perhaps there was some interaction - that perhaps I bunged the address or something; not so. The expander counts merrily from 0 to 256... the clock remains stubbornly 04:04.

Similar issues anyone? Thoughts? Advice? Anything...? If you think it might be code, I'll post it, but I doubt that's an issue as both devices work independently - without reprogramming...

[andybarrett1]

Check the address's is what comes to my mind.... Could you post the circuit ?

[towlerg]

If each device works on its own, then you must have the correct address's and (probably) they have correct pullups. Perhaps you have double pullups? As Andy said, post a circuit and some code. ASAIK there should be no connection between that RTC backup battery and Vcc.

George

[Amoque]

I have checked the addresses several times. You know how it is when you can't figure it out... check once, poke around a bit, check again... more frustration... get out the data sheets and check again...

I could draw up the circuit, but is so dang simple I wired it from memory: Programming port, reset button, 4 bit 4x20 LCD and I2C - which, as I say, was a module from SparkFun. When that failed I ordered a bare chip from Digi-key and wired that- it also worked perfectly, finally a module from Banggood which, again, works perfectly - until the PCF port expander is plugged in, then 04:04 on the clock... until the PCF is unplugged.

I don't think I mentioned it previously, but the PCF continues to work when both are plugged in - its only the clock that fails.

As a work around can I designate another I2C bus on other pins? HATE admitting defeat, but...

EDIT: Only 1 set of pull-ups.

[andybarrett1]

I am still not convinced about the addressing....purely as I chase "my own" tail lots of times on similar bits of hardware.
Usually binary read from wrong end (inverted)

If you draw out what you do have .... You might just see the problem yourself. Plus it helps us help you !

[towlerg]

It still seems to me that is the slaves work individually then you must have the correct address. What RTC are you using? PCF8574 is definitely an 8 bit addressable device.

George

[andybarrett1]

You Didn't mention pull ups (Downs) on the A0,A1,A2 Lines ?

You did mention pull ups on the SDA,SDL though .

BR
Andy

[rsocor01]

The problem might be with the PCF8574 chip. The datasheet that I downloaded says that it works at 100 kHz. If your clock works at 400 kHz that might be a problem. Try configuring the I2C interface at 100 kHz only. Try this line at the beginning of the program,

DEFINE I2C_SLOW 1

[andybarrett1]

Another Idle thought:-

What are you using as a Power Supply for the circuit ?

Try another source of power ??

[Amoque]

I'll look again at the addresses and try to find some way to provide a drawing or schematic and code (after work tonight). I was hoping it was a simple oversight someone might recognize without, but something more is needed; these are things I should have had ready or posted with my OP.

I tried slowing the I2C to no avail, but I will try again; no need for particularly fast communications anyway. Both addresses are grounded to 000. Power supply is bench type, regulated, well filtered, and stable. In fact, I have another, smaller, PS to dedicate to this project - same issue with it as well.

I noticed this morning that the clock initializes correctly and displays the correct time during the first main loop, then fails on subsequent reads. I know I'm writing to the RTC1307, because the time will display properly if the port expander is unplugged - reading seems to be the issue. The subroutines used are verified - read/ write bit set as it should be - and tested from other projects (and previous versions of this code).

All good suggestions and just having your interest is motivating... Let me do some more work, double check everything suggested so far and get back to you with some additional information.

Thanks again...

[andybarrett1]

OK...

Will keep a look out for feedback :-)

[towlerg]

I'm guessing that you don't have scope or logic analyzer to actually see whats going on, I think thats the only way you're going to fix this. In this case I suspect a scope would be more helpful (USB from eBay £50 ish - for this you don't need lots of bandwidth) and as they are so cheap, Salea knock off (eBay £6). And before the winers start, a) Salea don't sell them any more and b) if you base your software on a reference design you shouldn't be surprised if people use alternate hardware.

George

[richard]

it works for me pbp3 pic16f1825 // ds1307 // pcf8574a either your code is wrong or your not connecting things properly

tested at 8mz an 32mhz the pcf8574a has no problem

                            
#CONFIG
   __config _CONFIG1, _WDTE_ON    & _FOSC_INTOSC   &_MCLRE_ON    &_PWRTE_ON 
   __config _CONFIG2,              _LVP_OFF   & _PLLEN_ON
#ENDCONFIG
         DEFINE OSC 32
         
            pkt var byte[11]
          MONTH VAR pkt[5]
          DATE  VAR pkt[4]
          HOUR  VAR pkt[2]
          MINS  VAR pkt[1]
          DOW VAR pkt[3]
          YEAR VAR pkt[6]
           SEC VAR pkt[0]
           cnt var byte

  
     osccon=$70    '8 MHz or 32mhz
         anselA=0        'dig i/o 
         ANSELC=0
      TRISC= 111111
       TRISA= 111110
       
   
     SDA         VAR PORTc.4       ; I2C Data pin
     SCL         VAR PORTc.3     ; I2C Clock Pin
pcf_Addr CON $78
rtc_Addr CON $d0       
      
       i2cwrite  sda,scl,rtc_Addr,0,[$80,$14,$11,3,$14,1,$14]  'SANE TIME AND DATE  
        i2cwrite  sda,scl,rtc_Addr,0,[$80]    'FORCE START IF REQ
        i2cwrite  sda,scl,rtc_Addr,0,[0]
 
  main:
  pause 2000
  i2cREAD  sda,scl,rtc_Addr,0,[str pkt \7 ]
  serout2 porta.0,84 ,[HEX HOUR,":", HEX2 MINS, ":",HEX2 sec, " - ", HEX DATE,"/", HEX MONTH  ,13,10]
  i2cwrite  sda,scl,pcf_Addr,0,[cnt]
  cnt=cnt+1
 goto main

[Amoque]

In preparation for providing a drawing, I stripped off the board the battery holder, socket, and crystal from the standalone 1307 I tried earlier (they were not wired, but were cluttering the board), then began commenting out the unneeded code to post the minimal circuitry and programming that demonstrated the problem. Somewhere along the way... it works as intended now.

You may recall that the last thread on this issue ended with my determination that it was some undiagnosed power issue related to backup battery voltage; I was not able to isolate the issue. Once again this is the case.

I am tempted to write it off as a bad soldier joint or poor connection; it hurts my pride to admit such - I was a hearing aid technician for 20 years and close tolerance work was my bread and butter; yet, I cannot think of any other cause or issue that might manifest itself in so frustrating a way.

I am looking now for a new DSO and I am convinced to get one with a logic analyzer. Issues like this are so demotivating...

Thank you all for your suggestions and your effort and advice, I appreciate it very much.