CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Warm Resets

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ali
Guest







Warm Resets
PostPosted: Thu Mar 30, 2006 9:43 am     Reply with quote

I'm wondering what the concensus out there is on using the "trick" of modifing your initialization to detect a "WARM" reset versus a true POWer ON "COLD" reset.. and what the members feel is the best way to handle these occurances.


Do you always create code to determine between as WARM and COLD reset and allow the system to "recover" from a WARM reset as if nothing had happened. ?

Do you always treat any reset as a COLD reset and re-initialize everything?

Have you ever had problems with "unexplained resets to the system?

Do you use an external Reset Device on your PIC chips to avoid the problem of unexplained resets?

Would your reset approach change any if your unit was to be on 24 hours a day for months at a time and a random reset would make the entire system useless until some one checked the unit. Which this check might not come for months.

Thanks in advance for your answers/comments
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Mar 31, 2006 4:13 pm     Reply with quote

Tell us more about your proposed product. Does it run from batteries
or a wall transformer ? Does it have a voltage regulator ? What is the
part number ? What filter capacitors are used with the regulator ?
Is there an input line filter ? Does your product run in an electrically
noisy environment ? Is there powerline noise ? Is there static
electricity ? Is the unit touched by anyone ? Does it have front panel
switches ? What connections does it have to the outside world ?
Ali
Guest







PostPosted: Sun Apr 02, 2006 11:49 am     Reply with quote

Thanks PCM Programmer for responding.
Here are more details about the product.

The product runs from batteries.
It does have a voltage regulator, a Holtek HT7533-1 3.3V 100MA LDO REG , 10uF caps on input and output.
The PIC part is a 16F648A.
It has front panel buttons wit the little carbon disks to make the connections. Those will be touched by humans to setup, but then that's
it. The unit also have an lcd glass. And it controls a solenoid valve which
is internal to the product.
Product is used outside so little static build up should occur. The
housing is plastic.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Apr 03, 2006 2:33 pm     Reply with quote

Quote:
The PIC part is a 16F648A.
Have you ever had problems with "unexplained resets to the system?

Here are some suggestions:

1. This PIC has been through five silicon revisions. The latest is rev A5.
You should make sure you're using the latest revision chip. I don't
know who your distributor is, but I know that Digikey will guarantee
that you get the latest revision if you ask for it. http://www.digikey.com

2. If the watchdog timer is enabled, make sure you reset it frequently
enough. The WDT runs from an internal RC circuit and the timeout
period can vary widely with temperature. Also, several of the CCS
libraries have an optional "restart_wdt" parameter, which can be
specified when you declare the library. (in the #use statement).

3. The 16F648A uses the "A"-style silicon technology. Based on
reading posts in this forum and elsewhere for several years,
I think the "A" chips are much more susceptible to electrical noise
problems than the "non-A" PICs. I avoid using them. You should
connect a 0.1 uf (100 nF) capacitor between the Vdd pin and GND
and place it very close to the Vdd pin.

4. If you're using a 2-layer board, then try to have the unused areas
of the board (including between groups of traces) be used as power
and ground planes. If you can't do that, then "grid" the power and
ground (i.e., a crosshatch pattern). Put Ground on the top side
and Power on the bottom side of the board. By using planes or
the grid, you greatly reduce noise in the power and ground traces.

5. If you have some unused pins on the PIC as floating inputs, the
input level could float to the trigger point and cause small noise
to be amplified to CMOS levels and be propagated into the chip.
Given that the "A" technology is susceptible to noise, this could
cause problems. All unused pins should be configured as outputs,
and set to a low level. (I'm assuming that no external components
are connected to these pins).

6. Make sure you have NOLVP in your #fuses statement.

7. If you're using the #separate directive anywhere in your program,
you need to check the .LST file (at the top) to see if the number of
stack locations used is 8 or less. Once you use #separate, the
compiler won't automatically prevent usage of more than 8 stacks.
If you use more than 8, the program will likely crash at some point.

-------------------------------------
To troubleshoot the problem:

A. Use the restart_cause() function at the very beginning of main(),
and print or display the result. This will tell you what caused the
reset.

B. To determine if the 16F648A is itself the cause of the problem,
try to cut down the size of your code so it's only 2 KB. Then
run the code and verify that you still have the reset problem.
Then program a 16F628 with the code. This is a non-A chip and
should be reliable. I use them in a product. If the problem
disappears, then you can blame the 16F648A. At that point, you
can try to trouble-shoot it further, or use a different PIC.


I know you had more questions than this, but I've got to do some work.
Ali
Guest







PostPosted: Tue Apr 04, 2006 6:06 am     Reply with quote

Thanks for the information...

Wish I had thought to look at that errata sheet before. This is my
first PIC and I didn't even think about it before we selected the part.
We were too worried about PRICE on this job that I started to just look at that, and nothing else.

I've used the restart_cause and found that I'm getting MCLR resets. occasionally. (Like once in a week)

I checked with ICD2 and I do have version A5 of the silicon.

I am using a two layer board.. and in the next rev I do have a substansial ground pour on it. Should have it soon to test out.

I have a .1uF cap on the VDD and GND.

I also do have #NOLVP in my fuses, and I'm not using the #separate command. And I've checked the list file and my stack is at 7.

With all this information you've provided I'm guessing that you don't like the WARM COLD reset trick at all. Am I correct?

Once I get the new boards in any suggestions on how to "cause" the problem.. instead of waiting around for weeks on end?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Apr 04, 2006 10:21 am     Reply with quote

Quote:
I've used the restart_cause and found that I'm getting MCLR resets. occasionally. (Like once in a week)


1. What components do you have connected to the MCLR pin ?
Describe the circuit.

2. What voltage do you measure at the MCLR pin ?

3. Post your #fuses and #use delay() statements.
Ali
Guest







PostPosted: Tue Apr 04, 2006 11:12 am     Reply with quote

Quote:
1. What components do you have connected to the MCLR pin ?
Describe the circuit


Circuit uses a 10K pullup to 3.3V and a protection diode. In my new board layout I've left room for a small cap to GND if necessary. And I've removed the Diode as It wasn't really necessary anyway.

Quote:
2. What voltage do you measure at the MCLR pin ?

With the diode in place, I measure about 3.16 Volts. Without it I measure 3.3V. (I've removed it from one unit to see if the resets still occur without it. I'll admit it has not reset yet.. but then again.. the one with the diode hasn't reset recently either.. but it did reset once last week.

Quote:
3. Post your #fuses and #use delay() statements.


Code:

#use    delay(clock=4000000,restart_wdt)    //Tell C about Clock
#pragma fuses INTRC_IO,WDT,PUT,NOPROTECT,NOBROWNOUT,MCLR, NOLVP, NOCPD
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Apr 04, 2006 1:13 pm     Reply with quote

I think the diode (in series with the 10K) will turn out to be the problem.

Read the section on "Vpp (/MCLR)" on this page.
It's about 2/3rds of the way down the page.
http://www.newfoundelectronics.com/isp%20guide.htm
I always remember this article. I only use a 10K resistor
between MCLR and Vdd.
Guest








PostPosted: Tue Apr 04, 2006 3:40 pm     Reply with quote

PCM:
Thanks for that great writeup. I have been using many different pics for quite some time and was not even aware of all these things. Perhaps you should label this as faqs and put it in the code library or something. Probably will be of great help to many people.
Ali
Guest







PostPosted: Tue Apr 04, 2006 6:33 pm     Reply with quote

PCM Programmer,
Thanks for all your assistance. You;ve been most helpful.

I hope that removing the diode is all that it takes to make this sytem more reliable. Though I plan on doing a little extra testing once the new board is complete just to be sure. I plan to do some through HOT /COLD testing and hope that will flush things out. I'm going to leave one with the diode in it as a "CONTROL" I hope. Any suggestions on other possible tests that might help flush it out would be greatly appreciated.



On the original question though, you never really answered nor anyone else for that matter.

Quote:

I'm wondering what the concensus out there is on using the "trick" of modifing your initialization to detect a "WARM" reset versus a true POWER ON "COLD" reset.. and what the members feel is the best way to handle these occurances.


I think based upon your answer I can say that you do not like WARM/COLD reset tricks as you specifically look to the hardware to eliminate these things (Though please correct me if I'm wrong) . I tend to agree I want solid hardware. but I've seen quite a bit of code posted on this forum utilizing the Restart_Cause result for different initializations. and I wonder when that becomes "OK" to do? Or what situations warrent such usage?

Just out of curiousity, and maybe to help others decide what to do I'd still be interested in the opinions on this one.

Thanks again for all your help... Very Happy
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Apr 04, 2006 7:23 pm     Reply with quote

I assume your concern is about the difference between a power-on reset
and an MCLR reset. That information is in the 16F648A data sheet.
Look in the section on Special Features of the CPU. Look at Table 14-6
and especially Table 14-7. There is a column for Power-on reset and
for MCLR reset. You can compare them and see the differences.

For example, one difference is the T1CON register. In a power-on reset
it comes up as all zeros. In an MCLR reset, it comes up unchanged.
If you're using Timer1, you will likely be calling the setup_timer_1()
function near the start of your program, so you're initializing it anyway.
It doesn't really matter what it comes up as. If you're not using Timer1,
it will come up as all zeros in both types of resets, because in the case
of an MCLR reset, it's unchanged and it was all zeros in the initial
power-up reset.

I noticed that you have Watchdog timer enabled. WDT is in the same
column as MCLR, so the same arguments hold.

So I think the answer is that you don't have to do anything special.
Any peripherals or variables that you're using will be initialized by your
own code near the start of main(). Anything that you're not using will
stay in the initial power-up reset state.
Ali
Guest







PostPosted: Wed Apr 05, 2006 7:12 am     Reply with quote

Actually in this instance I'm more worried about my application code.
I'm running a real-time clock in this code and upon an official powerup reset I ask the user to SET the time. After that I really don't want the
user to have to reset the time.

So the problem is.. Do I assume that any reset is BAD.. and requires my application code to be completely reset, meaning they have to reset the time.. Or do I allow an MCLR reset, to pass by without resetting my application code and requesting the user enter the time again. (Taking into consideration of course any processor registers that get reset by MCLR and initializing only them. )

The other problem is that I occasionaly get a 25 for the Normal PowerUp value of a RESTART CAUSE instead of 24. I'm not sure why that happens yet. I sent an email to CCS but have not gotten a reply just yet.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Apr 05, 2006 12:22 pm     Reply with quote

Quote:
After that I really don't want the user to have to reset the time.

The design should have used a battery-backed Real Time clock,
such as DS1307. Then you set it once and don't have to set it
upon each power-up.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group