DS1302 high current problem

[Matias]

Hallo! I have a problem using the DS1302. It works fine, but sometimes starts with a high consumption of current, when it happens I disconnect the supply (the RTC still works because it has a Batt) and I connect again... but the problem stay there. When I disconnect the supply and the Batt, the problem is fixed. I'm using PIC18F452 and the DS1302.c, but I think that there is problems when I init the RTC. Have you ever had the same problem? what can I do?

[PCM programmer]

Are you using the Trickle Charge feature ? If so, disable it.

[Matias]

Yes, I think so. my init function is:

[PCM programmer]

What is the current consumption when it's very high ?

Also, you have modified the CCS driver in many ways. For example,
the first thing CCS does in EX_RTCLK.C is to call rtc_init(), as shown
in this example of their code:

[Matias]

may be, I'll put rtc_init first. The consumption is so high that the RTC get very hot. thanks.

[PCM programmer]

I would check the connections in your circuit. What type of battery are you using ?

[PCM programmer]

Also your symptom of the chip getting very, very hot at start-up
could be caused by a CMOS latch-up problem.

[pastruga]

Did anybody find the cause of the problem? Almost 20 years later, I am encountering the same issue.
I'm using the same chip model: a DS1302 Real Time Clock with an Arduino Board.
The clock works fine for a couple of days, or maybe weeks, but sometimes suddenly is starting to draw high current and becomes hot and I am not able to communicate with the module.
If I unplug it and take out the battery, the chip starts functioning again as nothing has happened.

[Ttelmah]

That doesn't sound quite the same. The original problem here was on
power-up. Your description sounds as if this is happening when running?.

What is your battery type & voltage?.
It is vital if using a lithium primary cell, that the trickle charge mode
is turned off. Otherwise it can cause the destruction of the cell.
There is also an issue if the power to the processor goes high before
the Vcc1 on the chip. This can cause an latch up to the input gates.

[temtronic]

DANG, anyone else shocked we've been 'playing with PICs' for over 2 DECADES ??!!!
I KNOW I have DS1302s some where.

[Ttelmah]

Only two decades!....

I actually had to point out to MicroChip when they originally did their
'history' entry, that I was using the 16C84 before they claimed it was
launched.
Originally assembler. Then an earlier C, and then CCS.

I've used the 1302 on several projects. Never had any issues, but I
was using rechargeable cells with the charge option enabled. Also it's
on the same board with the micro, so no supply sequencing issues.
Also code in general always waits a little after power on, before talking
to the chip. So lines are left floating till the supply is fully established.

I think the internal voltage in the chip does take a tiny amount of time
to rise when Vcc exceeds Vcc1, so you have to be careful not to drive
the SCL and I/O line up, until this time has passed or you can be reverse
biasing the gates on these lines. So a few uSec delay needed before the
init at boot.

[pastruga]

The setup is powered by cable from a laptop USB port. I'm using it for testing.
In my case, the problem also occurs on power up. It works just fine for days but sometimes in the evening I turn it off and the next morning when I power it up it doesn't work anymore and the chip is hot. I quickly turn it off, take out the CR2032 cell, put it back, power everything up, and it works again.
One time, I didn't realized that the problem occurred and didn't unplug it. After many minutes I just mistakenly touched the chip and realized it was hot, I could barely touch it.
I took out the power and the cell battery, rebooted and it started to work again.
I am amazed that the chip that usually draws only about 300nA did survive such a high current and such high temperature for such long. I didn't measured the current draw when it was hot, but the chip was so warm that it could barely be touched.

When the problem occurs if I want to read the time from the chip I only get 00:00:00. I am not sure if this is just a wrong reading or if somehow the internal memory has been changed to 0.
I didn't played with the "trickle charging" bit, so the charging should be disabled. My program only pulls the time and doesn't change anything. I'm playing with a GSM module also, the module is powered from a separate PSU, but shares a common ground. The GSM radio interference might play a role, but I am not sure.

I'm using non chargeable CR2032 battery.
Last time when the problem occurred, I took out the battery and measured it. It only showed 2.9V and it was warm also. I thought that the battery might be empty so I bought another one and replaced it. The new battery measured 3.1V.
Strangely, after waiting a couple of hours I found on the table the old battery and decided to measure it again. It's voltage was close to 3V, so in meantime the battery somehow recovered, its voltage started to increase.
I suspect that when the problem occurs the battery is short circuited, not overcharged.

I will try to pay attention to the boot up procedure and introduce a delay before driving SCL and I/O lines.

[Ttelmah]

It sounds to me as if the input gates are getting into CMOS lockup.

Do you delay at boot before calling the init function?.
How large are the pull-ups on the two I2C lines?.
How is the Vcc connected to the PIC and chip?. Both from the same
connection?.
The CR2032, may well have been delivering the overload current when the
Vcc was switched off. The condition would not clear till both supplies are
removed. Hence it's behaviour.

You'd get this if somehow the PIC or the drive resistors have a higher voltage
than the chip has internally. So a glitch on it's supply or power being applied
to these before the chip.

[pastruga]

I introduced no delay before the init function. Thank you. This might be the cause of the problem, I will try with a two seconds delay.

I am not using pull-up resistors because in the datasheet of DS1302, page 3, is noted that the pins are internally pulled down using 40k resistors. So, I think I don't have to pull them up as I usually do with the pins of other IC's.
The communication is not I2C, it's a kind of synchronous serial communication specific to this chip.

The chip is connected to the same VCC as the microcontroller, on the same wire. I didn't used a filtering capacitor attached to the VCC of the clock chip because the chip is also connected to the CR2032 battery so I considered unnecessary to add a filtering capacitor. The chip should be able to withstand power failures, or at least that's what I thought.
A capacitor and a zener in parallel are always useful, but since there is a battery involved and the datasheet doesn't state anything about filtering caps, I just skipped them for testing.

For the moment, I am thinking to a "dirty" work-around, I am thinking to connect a 1k resistor in series with the chip. Since the current draw of the chip is so low, the voltage drop would be insignificant when the chip works as it should, but when it starts to draw high current, the resistor would limit the current and stop it from overheating. This is not a proper solution but a temporarily work around.

[Ttelmah]

Power failure bears no relation to glitches.
The chip is powered from the battery when the supply falls below the
battery voltage, but is dependant on it's supply being smoothed when it
is powered from the Vcc. All chips require decoupling.
The data lines to the chip must never go above it's supply voltage. If
it switches to it's battery supply while data is still arriving, this will
cause a latch up. All wires act as antennas, and will pick up glitches.
These need to be suppressed.
Not having pullups is correct for this chip, but the PIC itself will
pull the lines up once it is driving them. If this takes the lines above
the chip's current supply you will then get latch up....
The resistor will stop the supply drawing huge currents, but these will
still come from the battery and flatten this.