i2c issues with PCF8563

QuadeHale

New Member
I have wired a PCF8563 to my 28x1 and as a test, I am using the following code:

'Clock Reader/Displayer
hi2csetup i2cmaster, %10100010, i2cslow, i2cbyte

writetime:
hi2cout 2, ($01)
debug
pause 1000

readtime:
hi2cin 2, (b0)
debug
pause 1000
goto readtime

all I wanted to do as a test, is write the seconds as 1 in the RTC, and then view those seconds incrementing as a test to see if the bus is okay.
viewing the sdl and sca lines on my ancient scope is difficult (read, nearly impossible to actually view as it has no "hold" feature) but things seem to be "okay".
is there any way see what's actually going on?

the chip supports i2cfast but I used slow just in case.
the confusion arises by the fact that a 255 is returned, which according to the picaxe BASIC manual is a hardware problem or the wrong i2cslave address is used. the hardware is fine (4.7k pullups, big ground plane, less than 1cm trace length on the data lines) and the slave address was pulled RIGHT out of the datasheet (the datasheet can be found at http://www.nxp.com/acrobat_download/datasheets/PCF8563_5.pdf). It mentions a "word address" but after further reading I have come to understand that the word address is actually just the "location" byte tacked on to the slave address, hence the "2" in the hi2cin/out command.
I'm completely lost, and haven't a clue what's wrong.

I'd also like to put in my two cents about this forum: the archiving completely screws up formatting making any code written nearly unreadable, and the search section is abominably buggy. However I do commend you all for your wisdom and experience, regardless of the forum software/administration options :D
 

Technical

Technical Support
Staff member
Your program is ok, but have you actually written 0 to control register 1 (address 0) to make sure the RTC is active? If not this then it looks like a hardware issue.

The archive sections of the forum do not always display correctly as they were imported from a completely different forum software database that used different formatting. However with a bit of tweaking they are still useful, hence the reason they are still available. You can also help program formatting in this current forum by using the requested [ code ] tags in your post - see the readme first thread at the top of the forum.
 

BCJKiwi

Senior Member
Have been running a DS1307 and been trying to source a DS1337+ without success - been waiting since November and through 3 order/re-orders for samples from Maxim/Dallas - all to try to get the i2c bus speed up from slow to fast!

So ordered and just received a PCF8563.
Have studied the AppNote as well as the datasheet and written the full set of registers as per the AppNote examples.

It simply does not function in place of the DS1307 at slow or fast bus speeds.
Put the scope on the bus and find there are no clock pulses - the bus is high all the time.

Does anyone have success with the PCF8563? There is very little info on the forum - or elsewhere - that I can find. Sample code would be much appreciated.

Code:
#picaxe 28x1
SetFreq m8
#terminal 9600
'####################################################################################
Initialise:
 
'Clock Reader/Displayer
hi2csetup i2cmaster, %10100010, i2cslow_8, i2cbyte  'fast tried as well
'  i2c Addr    Register    Reg 0      Reg 1    Seconds Mins   Hrs  Days   Dow  Cent/Mo   Year     MinAlarm  Hr Alarm  Day Alarm WkDy Al   CLKOUT   Tim ctrl  Timer
hi2cout [%10100010], %00000000, (%00000000,%00000000,%01011001,%01011001,%00000001,%00000001,%00000001,%00000010,%00001000,%10000000,%10000000,%10000000,%10000000,%10000011,%00000000,%00000000)
 
readtime:
hi2cin  [%10100011], %00000010, (b0)
bcdtoascii b0,b1,b2   'convert BCD to ASCII
sertxd("Time  -- ",#b1,#b2,cr,lf)
pause 4000
goto readtime
Any help much appreciated.
 
Last edited:

QuadeHale

New Member
I'm defenitely getting activity on both clock and data lines - I just can't tell what that activity is, exactly. Indeed, an earlier program I wrote for the RTC wrote to every register as ultimately I intend to do. Alas, something is still not right.
Agreed with BCJ, the PCF8563 should work great, it's a fantastic chip according to the datasheet, it's just too bad we can't get the damn thing to work :mad:.
 

Dippy

Moderator
I had some issues with this chip when using another compiler. Electrically there were some power wastage issues under certain battery/circuit design conditons but can't remember specifics. Went back to dallas and used DS3232, far superior.
 
Reading the data sheet, 10100010 is the address used for writing and 10100011 should be used for reading.
so in theory:
Code:
'Clock Reader/Displayer
hi2csetup i2cmaster, %10100010, i2cslow, i2cbyte
writetime:

hi2cout 2, ($01)
debug
pause 1000

hi2csetup i2cmaster, %10100011, i2cslow, i2cbyte

readtime:
hi2cin 2, (b0)
debug
pause 1000
goto readtime
As explained in the datasheet, the bus while not in use is high.
 
Last edited:

BCJKiwi

Senior Member
Have the R/W bit covered

Code:
readtime:
hi2cin  [%10100011], %00000010, (b0)
The code is in a loop - zero bus activity
 

Technical

Technical Support
Staff member
Reading the data sheet, 10100010 is the address used for writing and 10100011 should be used for reading.
Technically correct, but you do not need to worry about bit0 in the PICAXE system. The PICAXE firmware ignores what is in the 'hi2csetup' command for bit0 and automatically corrects it to 0 for a hi2cout or 1 for a hi2cin.

So 1010 0010 and 1010 0011 in the setup are the same as far as the PICAXE is concerned.

Have you tried a different 32KHz crystal - the DS1307 wants a 12.5pF, the PCF a 10pF with adjustment cap.
 

BCJKiwi

Senior Member
The crystal has unspecified capacitance and the suppliers used (and others I've checked) don't specify the capacitance.

Have measured it with DMM and get 1.08nF ~ 11pF. Scratch that - the pf spec what the RTC exposes to the crystal, not the crystal itself - it's what the crystal is designed to work against.

This crystal works fine for the DS1307. The PCF8563 was tested without trim cap and then with fixed 5 and 10pF trim caps.

Frequency meter shows there is output on CLKOUT at the default 32kHz with or without the trim caps - but this is present if the clock runs or not.

Crystal spec - provided it oscillates - is all about time keeping accuracy.
However the scope shows no action on the i2c bus. However if I disconnect the SDA line from the PCF8563, then the bus comes back to life!
 
Last edited:

QuadeHale

New Member
One of the boons of the PCF8563 is that it has an internal crystal and apparently shouldn't need an external one. Unless I read the datasheet wrong, there's an internal oscillator, which should eliminate the need for an external crystal. It's the whole reason I really picked this RTC...

From Page 4:
The PCF8563 contains sixteen 8-bit registers with an auto-incrementing address register, an on-chip 32.768 kHz oscillator with one integrated capacitor, a frequency...
 
Last edited:

Technical

Technical Support
Staff member
Nope, an integrated oscillator capacitor does not mean it does not need a crystal! See the typical circuit and recommended crystalload capacitance value (10pF) towards the end of the datasheet.
 

QuadeHale

New Member
Well, I'll put in a crystal then and let you know how it goes. If I get it to work, then I'll post up working code for it at that time. Here's hoping...
Thanks for the tip. They should make that a little more clear in the datasheet then >.< or, maybe I'm just retarded.
 

QuadeHale

New Member
Let me ask this then -
In the application information schematic, they have a variable cap between OSCI and ground. Is that necessary? Probably not a variable one, but I'm not following why one would be necessary at all.
 

QuadeHale

New Member
After reading that document, my understanding of how RTC's work in general was vastly improved. However, it still didn't quite answer my question about whether it's absolutely necessary, or whether I could just bridge to ground. After all, the signal coming off of the crystal to OSCI is AC and will pass right through the cap. I only bring this up because I'm not leaving the clock "on" all the time - I need it to measure in times of half an hour or so, and use its timer function. I'm also not worried about tempco. The PIC will only be checking on the RTC every 5 seconds or so and the PIC doesn't do the same thing between every 5 second check, so I didn't want to rely on crapshooting a target time with the PIC when I could just set a timer in the RTC and then check it every now and again to see if it's done. I'm not concerned about ppm accuracy, even if i'm off by 10 seconds for a half hour I'm still okay with that.

So should I join OSCI and pin 1 of the crystal to ground, OSCO and pin 2 together, or leave the OSCI/crystal pin 1 floating? Does the crystal NEED that pulldown?
 

Dippy

Moderator
I really think, with respect, that you should read up about oscillators and resonant circuits. Until you get your head around that you won't see the point of the capacitors. There's more to a capacitor than just an 'AC resistor'.

I really can't see the benefits of switching the RTC off and on when you want it, but that's up to. Especially when you have the start-up times described (very clearly) in that document.

Don't call Ctrim (Cext) a pulldown, because it ain't.

And if you don't the osc going properly then your read/writing will be junk.

Construct the circuit as they suggest, they have been making RTCs for quite a long time and I would guess that they know what they're up to by now :)

But, for your own peace of mind and if you've time to spare, get an oscilloscope and ground the pins by all means and watch the scope display.

If you don't need accuracy then why not use a monostable e.g. 555 ??
 

BCJKiwi

Senior Member
In order to just get the RTC functioning, the crystal should be OK on it's own. The trimming capacitors are all about timing accuracy.

As stated above, I have tried with and without trimming capacitors and get no difference - but then, my problem could be different from yours.
 

QuadeHale

New Member
The reason I don't use a 555 is because I want progress updates (ie. a visible timer) displayed on an LCD. The RTC doesn't turn on and off every half hour - it's on all the time. My question was actually what BCJ answered - will the RTC work with a floating crystal, and apparently it will. I'm not worried about timing accuracy because it only needs to be even remotely accurate for periods of half an hour.

In any case, I'll get this crystal strapped on and post some code up once I get the PCF8563 working with the PICAxe.
 

QuadeHale

New Member
Argh

Still no luck. I'm getting $FF returned on everything, and i'm absolutely positive that this beast is wired correctly, trimcap and everything. Am I messing up some settings in my hi2csetup line?
Code:
hi2csetup i2cmaster, %10100010, i2cslow, i2cbyte
 

hippy

Ex-Staff (retired)
That HI2CSETUP looks okay to me, the PICAXE is an I2CMASTER, the RTC address is $A2/$A3, it can run on a I2CSLOW bus, and the register address is I2CBYTE.

Getting $FF back suggests the RTC isn't responding. Things I'd suspect and check are ...

Not initialising the RTC if necessary
Not reading the correct RTC registers
Not allowing enough time between accesses to RTC
Accessing RTC before it's come out of POR
Incorrect connections on SDA/SCL
Missing or wrong value pull-ups
RTC oscillator not running as it should be
Incorrect RTC supply voltage
 

QuadeHale

New Member
I got it to work. Turns out the problem is that I'm just an idiot, and I forgot to put the chip back in the socket last time I took it out. The settings I used:
Code:
hi2csetup i2cmaster, %10100010, i2cfast, i2cbyte
It seems to work okay, but any register of greater time than the day (ie. weekday, month/century, years) wigged out and seems to randomly change values, but the seconds through hours are very reliable. I used a floating crystal (ie. no trimcap), so I can tentatively say that it works for anyone else trying to do it, but I would guess that this is one of the possible reasons for the wigging-out registers. I have learned alot since the last time I picked up this project, and I thank you all for your assistance. If anyone has an alternative reason the weekday-and-up registers would randomly change, it'd be appreciated...
 

hippy

Ex-Staff (retired)
The randomly changing registers may have bits used in them which change more frequently than you'd expect. You'd have to check the datasheet.
 
Top