- How to Un-Hang a DS RTC Chip Stuck in I2C La-La-Land ???
- Posted by B1ackwater on June 10th, 2008
I've been working with a Real-Time-Clock chip, the DS-1337+, and
noticed that if the final I2C read operation isn't accompanied
by a 'no-ack' then I2C communications hang-up shortly thereafter.
The PIC language I'm using (MikroPascal) does not have a proper
"time-out" for I2C operations, so everything hangs until the
watchdog finally kicks in, which is rather inelegant.
The docs say the 'no-ack' condition is necessary - but communications
are known to fail once in a great while (so I've heard) and that means
that one out of 'X' READ commands will be malinterpreted.
What the datasheet does NOT say is what one can DO about this
situation - beyond cycling power on the RTC chip to reset
everything.
No biggie for something sitting on your desk ... but my app is
going to way out 'yonder "in the field" and needs a way to cope
with any I2C hang-ups on its own.
Is there a decent way to UN-hang a Dallas RTC chip, one that
doesn't destroy the time/date/alarm registers ?
Any info helpful.
- Posted by Tauno Voipio on June 10th, 2008
B1ackwater wrote:
If your code cannot terminate the read by a non-ACK,
it is violating the base I2C specification - no can do.
--
Tauno Voipio
tauno voipio (at) iki fi
- Posted by James Beck on June 10th, 2008
In article <484e9457.14863562@news.east.earthlink.net>, bw@barrk.net
says...
hung?
- Posted by Frank Buss on June 10th, 2008
B1ackwater wrote:
You could implement the I2C communication yourself, maybe the MikroPascal
implementation is buggy? If the DS-1337+ really hangs, you can try to send
some stop conditions manually, this solves hanging I2C device problems
sometimes.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
- Posted by B1ackwater on June 13th, 2008
On Tue, 10 Jun 2008 17:12:53 GMT, Tauno Voipio
<tauno.voipio@INVALIDiki.fi> wrote:
The code CAN ... however my concern is that the inevitible
communications error will result in the RTC *not* getting
it's read-with-noACK eventually ... or more often than
eventually. Seems nobody added error RECOVERY to their
list when designing these chips. Imagine some app on
the bottom of the sea, or on Mars ... you'd be screwed.
A watchdog can reset the CPU ... but not an RTC chip,
not without nuking the time/alarm settings too.
Oh well, a redundant RTC, only accessed in the event of
a watchdog reset ....
- Posted by B1ackwater on June 13th, 2008
On Tue, 10 Jun 2008 13:30:26 -0400, James Beck
<jim@reallykillersystems.com> wrote:
Seems that the problem hangs the RTC chip itself. A few
reads or writes past that missed read-with-noACK and
it just clams-up. You can sent it starts and stops all
you want, but it won't talk again until you cycle the
power ... and zap all the needed settings in the RTC.
You'd think there would be some species of watchdog
IN the RTC chip. Maybe not ....
- Posted by B1ackwater on June 13th, 2008
On Tue, 10 Jun 2008 19:42:28 +0200, Frank Buss <fb@frank-buss.de>
wrote:
Ah so ... I'll do some experiments and see.
MikroPascal doesn't have a 'timeout' for I2C
functions. The program will wait forever for
the result from a READ command ... at least
until the CPUs watchdog resets everything.
Comm errors in electically/RF-noisy environs aren't
exactly rare no matter HOW well you try to shield
everything. The CPU needs to be able to cope with
"stuck" I2C peripherials - and cycling the power
on an RTC chip kinda defeats the purpose.
Anyway, an experiment is needed to see whether
it's the RTC that's hung, or just MikroPascal.
Might have to write or borrow an alien I2C
routine ... one that DOES have the sense to
give up after awhile.
- Posted by James Beck on June 13th, 2008
In article <4852ea4d.3776781@news.east.earthlink.net>, bw@barrk.net
says...
I'm probably blowing smoke here, but have you tried pulling SCK and SDA
low and holding them for 5mS or so when you power up to kinda' start
with a fresh I2C slate? I don't know if it will help or not and I can't
find the reason why this was done, but I had some canned routines from a
vendor that did this in their init_I2C() routine. Just a thought, and
it wouldn't hurt to try.
- Posted by Paul E. Bennett on June 14th, 2008
B1ackwater wrote:
What is interesting in this thread is that the OP hasn't considered the
need to re-write the I2C sub-routines so that he builds in the required
timeout functions. If the MikroPascal doesn't permit this then consider
changing to a decent programming language.
--
************************************************** ******************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
************************************************** ******************
