DS1302 error?
Ozzie Neil
Posts: 16
I have a Parallax prototype board 32111, it has a DS1302 on it. i thoroughly recommend this board by the way.
I downloaded an object and set it all up, worked a treat, no problems at all. I transferred it to a pcb board and it all appears to work ok, it accepts all prompts etc but when it kicks off it displays the following
65:65:65, 65 65 65 65
65:65:65, 65 65 65 65
65:65:65, 65 65 65 65
it repeats this about once a second.
The crystal isn't far away, a few millimetres at most and sits across pins 2 and 3.
Having read some of the threads in this forum placement of the crystal seems important, my knowledge isn't that extensive but given it responds once a second i don't see that the problem could be with the crystal.
Happy to hear some thoughts on this
I downloaded an object and set it all up, worked a treat, no problems at all. I transferred it to a pcb board and it all appears to work ok, it accepts all prompts etc but when it kicks off it displays the following
65:65:65, 65 65 65 65
65:65:65, 65 65 65 65
65:65:65, 65 65 65 65
it repeats this about once a second.
The crystal isn't far away, a few millimetres at most and sits across pins 2 and 3.
Having read some of the threads in this forum placement of the crystal seems important, my knowledge isn't that extensive but given it responds once a second i don't see that the problem could be with the crystal.
Happy to hear some thoughts on this
Comments
thanks for looking at my question.
The hardware was purchased from Parallax, the markings on the chip are: DS1302. There are some other lines on it but are difficult to read even under a magnifying glass but appear to be 0882A4 and I24AF. the crystal has S551 on it and is connected across pins 2 and 3. I have a 1K resistor on I/O, 3v3 to Pin1 and no connection to Pin8, i did jumper 1 and 8 just in case but as i suspected made no difference.
The code i downloaded from the object exchange forum, i changed the pin numbers rtc.init (4,5,6) to 2,0,1 to match my board layout. Like i mentioned the code works fine on the design board.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
SN : "Simple_Numbers"
rtc : "DS1302_full"
debug : "SerialMirror" 'Same as fullDuplexSerial, but can also call from subroutines
VAR
byte hour, minute, second, day, month, year, dow
byte cmd, out
byte data[12]
PUB main|i,_month,_day,_year,_dow,_hour,_min,_sec
waitcnt(clkfreq * 5 + cnt) 'wait 5 secs, start FullDuplexSerial
Debug.start(31, 30, 0, 57600)
Debug.Str(String("MSG,Initializing...",13))
'==================================================================================
'call this function each time the propeller starts
' rtc.init( 4, 5, 6 ) 'ports Clock, io, chip enable
rtc.init (2, 0, 1)
'==================================================================================
'set time
debug.str(string("=========== DS1302 demo ===========",13))
debug.str(string("enter 1 to setup ds1302, 0 to proceed on to demo without setting time",13))
if(debug.GetNumber<>0)
debug.str(string("enter month (1-12)",13))
_month:=debug.getnumber
debug.str(string("enter day (1-31)",13))
_day:=debug.getnumber
debug.str(string("enter year (00-99)",13))
_year:=debug.getnumber
debug.str(string("enter day of week (1-7)",13))
_dow:=debug.getnumber
debug.str(string("enter hour (0-23)",13))
_hour:=debug.getnumber
debug.str(string("enter minute (0-60)",13))
_min:=debug.getnumber
debug.str(string("enter second (0-60)",13))
_sec:=debug.getnumber
'call this function only after DS1302 power on
rtc.config 'Set configuration register
'call this function to set DS1302 time
rtc.setDatetime( _month, _day, _year, _dow, _hour, _min, _sec ) 'month, day, year, day of week, hour, minute, second
'==================================================================================
'change the tricle charger setup from that currently defined in the config function
'Trickle charger setup tc_enable diodeSel resistSel
' | | |
rtc.write(rtc.command(rtc#clock,rtc#tc,rtc#w),(%1010 << 4) + (1 << 2)+ ( 1 ))
out:=rtc.read(rtc.command(rtc#clock,rtc#tc,rtc#r))
Debug.Str(string("Trickle charge register contents = "))
Debug.bin(out,8)
Debug.Str(String(13,13))
'==================================================================================
'write data values to ram registers
repeat i from 0 to 30
cmd:=rtc.command(rtc#ram,i,rtc#w)
Debug.Str(string("Writing RAM address "))
Debug.Dec(i)
Debug.Str(string(" cmd byte = "))
Debug.Bin(cmd,8)
Debug.Str(String(13))
rtc.write(cmd,i)
Debug.Str(String(13,13))
'==================================================================================
'read data values from ram registers
repeat i from 0 to 30
cmd:=rtc.command(rtc#ram,i,rtc#r)
Debug.Str(string("Reading RAM address "))
Debug.Dec(i)
Debug.Str(string(" = "))
out:=rtc.read(cmd)
Debug.Dec(out)
Debug.Str(String(13))
Debug.Str(String(13,13))
'==================================================================================
'write data to registers 0-11 in burst mode
Debug.Str(string("Writing RAM data in burst mode"))
repeat i from 0 to 30
data:=30-i
cmd:=rtc.command(rtc#ram,rtc#burst,rtc#w)
rtc.writeN(cmd,@data,12)
Debug.Str(String(13,13))
'==================================================================================
'read data registers 0-11 in burst mode
Debug.Str(string("Reading RAM data in burst mode",13))
cmd:=rtc.command(rtc#ram,rtc#burst,rtc#r)
rtc.readN(cmd,@data,12)
repeat i from 0 to 11
Debug.Str(string("Data "))
Debug.Dec(i)
Debug.Str(string(" = "))
Debug.Dec(data)
Debug.Str(String(13))
Debug.Str(String(13,13))
'==================================================================================
'read date and time, once per second
repeat
rtc.readTime( @hour, @minute, @second ) 'read time from DS1302
rtc.readDate( @day, @month, @year, @dow ) 'read date from DS1302
Debug.str( SN.decx(hour,2) )
Debug.str( string(":"))
Debug.str( SN.decx(minute,2) )
Debug.str( string(":") )
Debug.str( SN.decx(second,2))
Debug.str( string(", ") )
Debug.str( SN.decx(dow,2))
Debug.str( string(" ") )
Debug.str( SN.decx(month,2))
Debug.str( string(" ") )
Debug.str( SN.decx(day,2))
Debug.str( string(" ") )
Debug.str( SN.decx(year,2))
Debug.Str(String(13))
waitcnt( clkfreq + cnt )
Exactly what do you mean by "when it kicks off"? Do you mean when you start it?
I know I had troubles in the past with RTC's when I had them on protoboards and I had either lots of long wires (5 inches or so ) hanging all around or perhaps a lack of decoupling caps. With wires hanging all around, the RTC's were very vulnerable to appliances in the room turning on and off, etc.
On the prototype board the jumper wires were about 6 inches, but like i said this worked fine.
On the PCB board the wires are longer because it does join via a DB25 and ribbon cable to the processor, probably about 9 inches. The DS1302 is mounted into a socket which is soldered on to my board. Tracks on the board are copper etching, not "wires". I have done continuity testing and all the connections are good and the etching is also good, I have no caps on this circuit.
I am connecting to a proto USB board from my pcb board, if worse comes to worse i could mount the DS1302 on the proto board. I also saw a thread where someone soldered the crystal onto the legs of the DS1302 itself, which i thought was a great idea. These 2 processes would shorten the wiring considerably, if that was the problem..
Neil
Neil,
of course this might not have anything to do with your particular problem, but it probably wouldn't hurt to attach one end of a 0.1uF ceramic capacitor to your power supply pin and the other end of this cap to ground. That should help decouple some of the pulses, tiny spikes, etc. that might dance around on the power line.
It might be overkill, but I've also made it a habit to use a ground plane for my RTC's when I make PCB's using them.
Please try to repost your code using the code tags I referenced in #4 above so that forum members can check your code for other possible problems.
Hope that helps.
I don't mean to insult your intelligence here, but Pin 8 is for your backup battery. In the event of a power shut down, this chip can not maintain the time and date without a battery backup. So I suppose you already know that if anything causes your main power to glitch and you do not have a backup battery, then you must reset the time and date. Right?
Since my board is a test board i can put a cap across the connections without any issues. if i had a CRO it would be interesting to observe noise on the supply line.
Thanks for your help
If this is resolved, please disregard.
I don't have one of these to play with, but that being said, after looking at the posts and data sheets I doubt your PCB is at fault. It should be a far cleaner environment than the original proto-kludge. At no point should anything be reading back > BCD 59 with the exception of the year.(unless it is getting it from the ram) But why always 65? Did you modify any of the supporting objects? Also, do you have a way to capture the BCD readback, (scope or logic tracer) from the DS1302 to further divide the data from the chip from your codes manipulation of the return data. I think that something changed in the code either a mod or mis-saved change.
Frank
Interesting, I may have to eat my words regarding the board not having an issue. I wonder if there is continuity between the Prop I/O pin and the data pin on the 1302. As Kye has noted 0xFF converts to 65, I would wonder why all I am getting is an 0xFF for all reads. But as mentioned earlier, do you have a way to capture the actual data at the prop and ds1302 I/O pins to see if there are 1s and 0s or constant DC level present.
Just another (hopefully not garden) path to follow on this one.
Frank
Good pickup about all 1's and a DC signal.. that was the clue.
Think i have found the problem. When i created the board i metered it all out to make sure tracks were continuous and that tracks weren't touching. I have just rechecked and have continuity between I/O and RST near my DB25 plug, i can't even see the join under a magnifying glass so ran a razor blade a few times between them and they are now no longer separated - they are close tracks. There must have been a smidgeon of solder joining the tracks that weren't there when i metered it earlier.
Reading the documentation RESET is HIGH during a read/write, since it was shorting to I/O I/O was presenting a HIGH all the time, the DC signal. I will need to check it all up later, i am using my prop USB on another project at the moment but it all makes sense.
Lesson learnt..
Neil
Frank
All works, stupid solder..
Neil