Searching \ for 'Bug with TO (TimeOut) flag in PIC16C5X' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16C
Search entire site for: 'Bug with TO (TimeOut) flag in PIC16C5X'.

Truncated match.
PICList Thread
'Bug with TO (TimeOut) flag in PIC16C5X'
1995\02\22@172834 by Michael Brinks

flavicon
face
Hi PIC users !

Here is, as promised, the info I have on the TO flag bug.

Note that the following is based on my experience only, so it may
be that I've misunderstood something. Therefore I would like to
here from anyone who can confirm or deny that this problem exists.

The story: In July 1994 I was working on a project that involved
PIC16C57. The electro-magnetic working environment for the PIC's
was pretty nasty -- to say at least, so I used the Watch dog to
catch any program run-aways.
The PIC's (8 of them) were controlled from a PC through a serial
connection. If one of the PIC's didn't respond to a request from
the PC, then the PC would reset the PIC's via the MCLR pin -- an
extra safety precaution.
The initialization code in the PIC's used the TO (TimeOut) bit in
the Status register to determine if a reset was caused by Watch dog
time-out or by a MCLR/power-up reset.

I use the CLRWDT instruction in the program, this instruction sets
the TO bit to "1", so after a MCLR reset the TO bit should be "1",
since a MCLR doesn't affect the TO bit (according to the manual).

However, I noticed that when the PC did a MCLR reset of the PIC's,
some of them would execute the power-up reset routine (as
expected), while others executed the watch-dog time out reset
routine. When I repeated the MCLR pulse, the pattern seemed to be
random, that is, at one time a PIC would do a power-up reset, the
next time a time-out reset...
The power-up/time-out ratio appeared to be around 50/50.
Very strange I thought -- must be a software bug... So I wrote a
short program that simply copied the TO bit to an output port
connected to a LED. When the PIC's were reset by MCLR, some of the
LED's turned on and some off - in other words: the same problem.

Well, maybe it's a hardware problem then ? I took a small PCB, put
on a PIC, a crystal, 8 LED's and a MCLR reset key. Wrote a program
that shifted the TO bit into a register, then copied the register to
the port, so that the LED's would show the status of the TO flag
after the last 8 resets.
After power up, the pattern on the LED's shifted one position each
time I did a MCLR reset or provoked a WDT time-out by stopping the
oscillator. The value shifted in after a WDT time-out was always
"0" (as expected) and the first TO bit shifted in after power-up
was always "1" (also as documented in the manual).
But after a MCLR reset the TO bit had an apparently random value :((

I discovered that the problem ONLY occurres when the prescaler is
assigned to the RTCC. When assigned to the WDT (even if set to 1:1)
then the TO bit isn't affected by MCLR reset.

I tried using different oscillator configurations and speeds -
didn't affect the problem.

Next I tried different supply voltages - no influence.

Then I disabled the Watch dog by blowing the WDT fuse - and I still
got random 1's and 0's in the TO bit !!!
Note that when the watch dog timer is disabled, then the TO bit
should *NEVER* be "0", since a watch dog time-out is the only event
that can set the TO bit to "0" (according to the manual).

I tested different devices. No difference between the EPROM / OTP
parts I tested.
Besides the 16C57's, the 16C55's also have the bug. 16C54 and 16C56
probably also, since they have the same core as 16C57, but I haven't
tested.
The 16C58A did not have the bug (Strange - since it's the same
core as the other 16C5X's ?  - or maybe not ? ).
The PIC16C71 does not have the bug. My guess is that 16C84, 16C64
and 16C74 work fine, since their core is based on '71, but I
haven't tested.


Well, what did I do ?
After discussing the problem with the local distributor (exatec),
I send the source code to them and later the hardware too. They
didn't come up with anything, so they passed the code/hardware to
Microchip and told me that "They (Microchip) are looking into my
problem".
I guess they look very carefully, because they have been looking for
more than 6 months now.


As stated in the beginning, I'm very interested in hearing from
anyone that have had the same or similar problems -- and perhaps
solved them ?
For the time being, my solution is simply not to use PIC16C54-57
in any new designs, where I need to determine the cause of reset.
This is not what I would call a satisfactory solution to the problem.


To summarize: The TO bug affects an application when:
* The TO flag is checked after reset and
* The reset may be caused by MCLR and
* The prescaler is assigned to RTCC and
* PIC16C54-57 is used


I hope that someone on the PICLIST can help me with this problem
- or, at least, that this information can help you from running
into a similar problem in future designs.


Michael Brinks

1995\02\23@022154 by Andrew Warren

face
flavicon
face
Michael Brinks (spam_OUTmbrinksTakeThisOuTspameinstein.ot.dk) wrote:

>For the time being, my solution is simply not to use PIC16C54-57
>in any new designs, where I need to determine the cause of reset.
>This is not what I would call a satisfactory solution to the problem.

Michael:

If you have the registers to spare, you may want to try simply loading a
few (four of them, perhaps) with known values.  Check the contents of
those registers on reset.  If they contain the proper values, you can
assume that the PIC was reset via MCLR.  If they don't, assume that the
PIC was just powered up.

-Andy


--
Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California

1995\02\24@035818 by Michael Brinks

flavicon
face
Hi Andy

You wrote:
> If you have the registers to spare, you may want to try simply loading a
> few (four of them, perhaps) with known values.  Check the contents of
> those registers on reset.  If they contain the proper values, you can
> assume that the PIC was reset via MCLR.  If they don't, assume that the
> PIC was just powered up.

Yes, useful tip for checking if reset was caused by power-up or
by MCLR reset.
However the subject were Watch Dog Timeout reset vs. MCLR reset.

According to the manual, the TO bit should indicate whether a
Watch dog timeout has occurred. But under some circumstances the
TO bit does NOT have the correct value. That is the problem.


  Michael

1995\02\24@205250 by Andrew Warren

face
flavicon
face
Michael Brinks (mbrinksspamKILLspameinstein.ot.dk) wrote:

>Yes, useful tip for checking if reset was caused by power-up or
>by MCLR reset.
>However the subject were Watch Dog Timeout reset vs. MCLR reset.

Michael:

Sorry... Alzheimer's Disease must be setting in.

-Andy


--
Andrew Warren - .....fastfwdKILLspamspam.....ix.netcom.com
Fast Forward Engineering, Vista, California

More... (looser matching)
- Last day of these posts
- In 1995 , 1996 only
- Today
- New search...