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.
How to Un-Hang a DS RTC Chip Stuck in I2C La-La-Land ???
Started by ●June 10, 2008
Reply by ●June 10, 20082008-06-10
B1ackwater wrote:> 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.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 by ●June 10, 20082008-06-10
In article <484e9457.14863562@news.east.earthlink.net>, bw@barrk.net says...> 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. > >Does the RTC go back to working after the watchdog barks, or is it still hung?
Reply by ●June 10, 20082008-06-10
B1ackwater wrote:> 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.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 by ●June 13, 20082008-06-13
On Tue, 10 Jun 2008 17:12:53 GMT, Tauno Voipio <tauno.voipio@INVALIDiki.fi> wrote:>B1ackwater wrote: >> 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. > > >If your code cannot terminate the read by a non-ACK, >it is violating the base I2C specification - no can do.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 by ●June 13, 20082008-06-13
On Tue, 10 Jun 2008 13:30:26 -0400, James Beck <jim@reallykillersystems.com> wrote:>In article <484e9457.14863562@news.east.earthlink.net>, bw@barrk.net >says... >> 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. >> >> >Does the RTC go back to working after the watchdog barks, or is it still >hung?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 by ●June 13, 20082008-06-13
On Tue, 10 Jun 2008 19:42:28 +0200, Frank Buss <fb@frank-buss.de> wrote:>B1ackwater wrote: > >> 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. > >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.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 by ●June 13, 20082008-06-13
In article <4852ea4d.3776781@news.east.earthlink.net>, bw@barrk.net says...> On Tue, 10 Jun 2008 13:30:26 -0400, James Beck > <jim@reallykillersystems.com> wrote: > > >In article <484e9457.14863562@news.east.earthlink.net>, bw@barrk.net > >says... > >> 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. > >> > >> > >Does the RTC go back to working after the watchdog barks, or is it still > >hung? > > 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 ....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 by ●June 14, 20082008-06-14
B1ackwater wrote:> On Tue, 10 Jun 2008 19:42:28 +0200, Frank Buss <fb@frank-buss.de> > wrote: > >>B1ackwater wrote: >> >>> 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. >> >>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. > > 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.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.. ********************************************************************
