 |
 |
| View previous topic :: View next topic |
| Author |
Message |
dpaul
Joined: 15 Mar 2005
Posts: 12
|
| Detecting /MCLR Reset During Normal Operation |
 Posted: Fri Mar 17, 2006 1:43 pm |
 |
|
Greetings:
I would very much like to detect a /MCLR reset which occurs during normal operations. The provided function reset_cause() only returns a value for WDT_TIMEOUT, MCLR_FROM_SLEEP, NORMAL_POWER_UP, and BROWNOUT_RESTART. Notably absent from this list is when /MCLR is brought low but it is not due to a power up situation. I need to preserve some variables when our reset button is pressed versus clearing them upon a true power up. These variable change constantly so neither is EEPROM a satisfactory solution.
I have looked into the PIC18FXXX RCON register directly. From my reading of the MicroChip PIC manuals, the relevant bits in the RCON register (/RI, /TO, /PD, /POR, and /BOR) are specifically stated to remain unchanged during a /MCLR reset during normal operations. From my perspective, this is most unfortunate.
As anyone devised a clever way to detect a /MCLR reset during normal operations that they are able to share? From both my reading and from testing various scenarios on the PIC18F8720 development board, I have not been able to devise a solution.
Thanks very much for your suggestions.
Sincerely,
Doug |
|
 |
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
| Re: Detecting /MCLR Reset During Normal Operation |
| Posted: Fri Mar 17, 2006 1:57 pm |
|
|
| Quote: | Providing a user with a hard-reset button is a sign of weakness.
My friend Steve |
In the spirit of the above quote, I would solve your problem with hardware. I would remove (or not expose to the user) the button from /MCLR altogether and leave /MCLR tied high with a 47k. I would then add a button, which would connect to a digital I/O pin or an interrupt (the latter might require debouncing). When your firmware detects that the button is pressed, it saves the data and then actually resets the PIC (via timing out the WDT, for example). |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Mar 17, 2006 7:28 pm |
|
|
CCS changed the code for the restart_cause() function in the last couple of compiler releases. Around v3.238 more result codes were added. In PCWH v3.245 the PIC18F8720 now has the following codes in the header file: | Code: | ////////////////////////////////////////////////////////////////// Control
// Control Functions: RESET_CPU(), SLEEP(), RESTART_CAUSE()
// Constants returned from RESTART_CAUSE() are:
#define WDT_TIMEOUT 7
#define MCLR_FROM_SLEEP 11
#define MCLR_FROM_RUN 15
#define NORMAL_POWER_UP 12
#define BROWNOUT_RESTART 14
#define WDT_FROM_SLEEP 3
#define RESET_INSTRUCTION 0 |
Too bad the implementation makes no sense at all | Code: | .................... int8 Cause;
....................
.................... Cause = Restart_Cause();
0028: MOVF FD0,W ; Read RCON register
002A: ANDLW 0E ; Filter bits 1 to 3 (POR, PD and TO)
002C: BCF FD0.1 ; reset POR bit
002E: MOVWF 0C ; Write result to Cause
.................... |
Sorry to say so, but this is complete rubbish! The resulting value for Cause will be in the set [0, 2, 4, 6, 8, 10, 12, 14]. This matches only 3 of the defined values, not to mention that it just won't work this way.
The Microchip documentation for the reset cause detection is minimal and it took me some time to understand how you can detect the various situations when so many bits are unchanged after a reset. The trick is to set all status bits to 1's on power-up, any sub-sequent reset will then set the corresponding status bit to a zero and creates a unique pattern. The correct way for the PIC 18F8720 is then:
1) power up
2) Copy RCON register to Cause variable, test STKFUL and STKUNF bits.
3) Set all bits in RCON except IPEN to 1's. Set STKFUL and STKUNF bits to zero.
At power up you will always find RCON to be '0--1 1100'. In all other situations your first startup had set all status bits in RCON, the new reset will create a new unique pattern by adding one ore more zero's. An exception are the stack underflow and overflow situations which leave all bits to 1's but will either set STKFUL or STKUNF bits. Still all 1's? Then it was an MCLR during normal operation. |
|
|
dpaul
Joined: 15 Mar 2005
Posts: 12
|
|
| Posted: Wed Mar 22, 2006 7:03 am |
|
|
Here's what the MicroChip folks had to say about this:
| Quote: | Refer to the description on Chapter 4.14 of PIC18FXX2 data sheet , both /POR and BOR bits must be set after Poer-On rset occur or Brown-Out reset occur respectively.
So , it's easy to match the description of Table 3-2 . The RCON value after Power-On is
0--11100 and the value shoud be 0--11110 after Brown-Out reset occur if the user set POR bit of RCON register to "1" after Power-On . POR bit only change to "0" when Power-On reset occur and leave unchange for the other kind of reset condition.
I believe the status bits in RCON can really help you to distinguish the reset type. But the BOR and POR bit have to be set once Brown-Out or Power-On reset occurs. |
|
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
