• AVR Freaks

Helpful ReplyHot!Finding the Cause of a Reset

Author
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
2020/04/04 14:59:04 (permalink)
0

Finding the Cause of a Reset

I'm using PIC16F1789 and I want to find the cause of a RESET. According to the datasheet the information of the following tables as well as the value of the variables __powerdown and __timeout, defines the cause of a reset.
But, to be honest, although I've searched in the forum I can't understand how to interpret the tables and more specifically the notations u = unchanged (compared to what?) or x = unknown (what value can I consider for this bit?).For instance, how can I distinguish the reset cause between the "Interrupt Wake-up from Sleep" and "MCLR Reset during Sleep" or between POR and BOR?
post edited by dirfys - 2020/04/06 15:53:43

Attached Image(s)

#1
ric
Super Member
  • Total Posts : 26942
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Finding the Cause of a Reset 2020/04/04 15:17:13 (permalink)
+2 (2)
dirfys
specifically the notations u = unchanged (compared to what?)

"Unchanged" means it won't be changed by the reset. It will still have the same value it had before the reset.
 

or x = unknown (what value can I consider for this bit?).

It will be random. It might be a 0 or a 1. Ignore it.
 

For instance, how can I distinguish the reset cause between the "Interrupt Wake-up from Sleep" and "MCLR Reset during Sleep" or between POR and BOR?

RMCLR is "u" for "Interrupt Wake-up from Sleep", and "0" for "MCLR Reset during Sleep", so it is your job to make sure it is "1" before you go to sleep.

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#2
pcbbc
Super Member
  • Total Posts : 1687
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/04 15:17:40 (permalink) ☄ Helpfulby dirfys 2020/04/06 15:38:37
+2 (2)
Unchanged means same as they were prior to the current reset. So if that bit was set/cleared by a previous reset, and you didn’t clear/set it to acknowledge it, it will still be in the same state on a subsequent reset from another cause (so in that case you may not be able to tell the difference).

To determine their cause of a reset, check the bits that are marked with 1 or 0 to ensure they are as indicated in the table. Then clear/set the required bit (if applicable) to show you have acknowledged it.
 
For example “MCLR Reset during Sleep” has a zero set for !RMCLR to indicate it. If you detect that type of reset you’d set !RMCLR = 1. Then when you get a subsequent “Interrupt Wake-up from Sleep” you’ll know it wasn’t a MCLR reset because !RMCLR is still 1.
#3
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/04 16:23:12 (permalink)
0
It's clear now. I suppose that the initial (default) value of the PCON register is the 1st line of the Table 5.3 even after the programming of the PIC.
I suppose that I must acknowledge the cause of reset right after a reset (by setting/clearing the appropriate bits of PCON register) in order not to miss any other subsequent reset.
#4
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/06 15:53:10 (permalink)
0
Thank you for your hints. I have two more questions:
  • I have implemented an RTC and when the PIC goes for SLEEP, it keeps counting the time by waking up the PIC every 1 sec. My question is if a MCLR RESET occurs during Sleep, is it possible to distinguish among the "MCLR Reset during Sleep" and the "Interrupt Wake-up from Sleep" or "WDT Wake-up from Sleep"?
  • What is the meaning of the 2nd & 3rd line at the attached table at my initial post?
#5
ric
Super Member
  • Total Posts : 26942
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Finding the Cause of a Reset 2020/04/06 16:27:51 (permalink)
+1 (1)
dirfys
My question is if a MCLR RESET occurs during Sleep, is it possible to distinguish among the "MCLR Reset during Sleep" and the "Interrupt Wake-up from Sleep" or "WDT Wake-up from Sleep"?

Yes. I already said how in post#2

  • What is the meaning of the 2nd & 3rd line at the attached table at my initial post?
I think they are saying those conditions will never happen.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#6
mbrowning
USNA79
  • Total Posts : 1741
  • Reward points : 0
  • Joined: 2005/03/16 14:32:56
  • Location: Melbourne, FL
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/06 16:39:18 (permalink)
0
If you care about the reset/wake up source, you read those two registers on reset/wake up and then immediately set all the “u” bits to “1”. Just think of all the “u” bits as being “1” because that’s how you set them and they are unchanged by the event you are testing for.

So to test for WDT wakeup imagine all those u bits are 1. If the resulting WDT wakeup bit pattern matches what you read, then that was the event that happened. Do that for every line in the table.
#7
pcbbc
Super Member
  • Total Posts : 1687
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/07 00:42:14 (permalink)
0
mbrowning
If you care about the reset/wake up source, you read those two registers on reset/wake up and then immediately set all the “u” bits to “1”. Just think of all the “u” bits as being “1” because that’s how you set them and they are unchanged by the event you are testing for.

Except for STKOVF and STKUNF which are the opposite (positive) logic. Those need to be set to “0” obviously.
#8
mbrowning
USNA79
  • Total Posts : 1741
  • Reward points : 0
  • Joined: 2005/03/16 14:32:56
  • Location: Melbourne, FL
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/07 02:28:59 (permalink)
0
What I get for squinting at the tiny table entries on my phone
#9
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/07 16:14:10 (permalink)
0
Apart from Stack Overflow/Underflow Reset which, although its detection is trivial, I don't know how to test it, I've detected the Power-on Reset (POR), WDT Reset (WDT), RESET Instruction Executed (SW RST), MCLR Reset during normal operation (MCLR) & WDT Wake-up from Sleep (WDT_S).
What I've done is to set immediately
PCON = 31; //0b00011111
 
 
 
__timeout = 0;
__powerdown = 0;

after the detection of the cause of Reset and the corresponding values after each test are the following:
//Test 1
 
PCON_before=0b00011100
TO=01
PD=01

POR
    -------------------

//Test 2
PCON_before=0b00001111
TO=00
PD=01

WDT
    -------------------

//Test 3
PCON_before=0b00011011
TO=01
PD=01

SW_RST
    -------------------

//Test 4
PCON_before=0b00010111
TO=01
PD=01

MCLR
    -------------------

//Test 5: PIC in SLEEP and I press a button at a 4x4 keypad matrix or it wakes up by TMR1
PCON_before=0b00011111
TO=00
PD=00

WDT_S
    -------------------

//Test 6: PIC in SLEEP and I press the MCLR button
PCON_before=0b00010100
TO=01
PD=01

MCLR

 
But if I set only,
PCON = 31; //0b00011111
then the results are the same except the test
//Test 5: PIC in SLEEP and I press a button at a 4x4 keypad matrix or it wakes up by TMR1
 PCON_before=0b00011111
TO=01
PD=01

POR

 
My question is if my approach of setting
PCON = 31; //0b00011111
 
 
 
__timeout = 0;
__powerdown = 0;

is correct and why when the PIC is in SLEEP mode and I press the MCLR button or the PIC wakes up either from TMR1 or from IOC, I don't get as cause of reset the MCLR Reset during Sleep or Interrupt Wake-up from Sleep, respectively?
During SLEEP my code is 
do
{
    SLEEP();
}
while (!(ISR_Ready2WakeUP || PIR1bits.RCIF));
 
                //****************//
 
//ISR function
 
//***** 5) INTERRUPT FOR CLEARING THE CMP2 FLAG ******//
else if (INTCONbits.PEIE == Enabled && PIE2bits.C2IE == Enabled && PIR2bits.C2IF == Enabled)
{
PIR2bits.C2IF = Disabled;
ISR_Ready2WakeUP = true;
}

//***** 6) INTERRUPT FOR CLEARING THE IOC FLAG ******//
else if (INTCONbits.IOCIE == Enabled && INTCONbits.IOCIF == Enabled)
{
IOCBF = Disabled;

ISR_Ready2WakeUP = true;
}

 
Is my testing approach wrong?
post edited by dirfys - 2020/04/07 16:20:54
#10
ric
Super Member
  • Total Posts : 26942
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Finding the Cause of a Reset 2020/04/07 16:42:04 (permalink)
+1 (1)
dirfys
Apart from Stack Overflow/Underflow Reset which, although its detection is trivial, I don't know how to test it,

In assembler, you could just code a CALL instruction with itself as the address to test overflow.
You could just execute a RETURN instruction from your top level code to to test underflow.
The C compiler makes it pretty difficult to do either of those silly things from normal C code.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#11
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/08 12:23:47 (permalink)
0
Unfortunately, I don't use the assembler.
post edited by dirfys - 2020/04/08 12:26:55
#12
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/09 11:40:20 (permalink)
0
Under "Window\Debugging\Output" menu, there is the "Disassembly Listing File".
Can I edit this file? Otherwise, how can I start the assembler?
#13
ric
Super Member
  • Total Posts : 26942
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Finding the Cause of a Reset 2020/04/09 16:04:37 (permalink)
0
dirfys
Under "Window\Debugging\Output" menu, there is the "Disassembly Listing File".
Can I edit this file?

no

Otherwise, how can I start the assembler?

If you were doing an all assembler project, you would have to treat it like another language, not C.
However for your purposes, you could just use some inline assembly, which XC8 supports.
Which mode are you using XC8 in?
C90, or C99?
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#14
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/10 06:02:46 (permalink)
0
For this project, I'm using C90.
#15
ric
Super Member
  • Total Posts : 26942
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Finding the Cause of a Reset 2020/04/10 16:24:48 (permalink) ☄ Helpfulby dirfys 2020/04/11 13:55:14
+2 (2)
I guess this would cause a stack overflow

void force_overflow(void)
{
#asm
go_here:
        call    go_here
#endasm
}

post edited by ric - 2020/04/10 17:08:40

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#16
dirfys
Super Member
  • Total Posts : 295
  • Reward points : 0
  • Joined: 2013/12/15 16:16:04
  • Location: Greece
  • Status: offline
Re: Finding the Cause of a Reset 2020/04/11 13:57:23 (permalink)
0
Thank you for your help.
I've tested it successfully, as well as the stack underflow by writing at the main()
#asm
RETURN
#endasm

post edited by dirfys - 2020/04/11 15:53:25
#17
Jump to:
© 2020 APG vNext Commercial Version 4.5