1. Home
  2. Embedded Programming
  3. How to Un-Hang a DS RTC Chip Stuck in I2C La-La-Land ???

How to Un-Hang a DS RTC Chip Stuck in I2C La-La-Land ???

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.

Reply to
B1ackwater
Loading thread data ...

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
Reply to
Tauno Voipio

Does the RTC go back to working after the watchdog barks, or is it still hung?

Reply to
James Beck

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
Reply to
Frank Buss

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 ....

Reply to
B1ackwater

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 ....

Reply to
B1ackwater

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.

Reply to
B1ackwater

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.

Reply to
James Beck

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...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.