Searching \ for '[PIC:] Distinction between RESET and BOWNOUT' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Distinction between RESET and BOWNOUT'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Distinction between RESET and BOWNOUT'
2011\10\10@040048 by IB Peter Feucht

flavicon
face
Resend, tag added, sorry.

Dear Piccers,

I developped a small battery operated device, using a 16F684, everything
works fine. Now the customer shows up, and wants to have any sort of
batt-low indication. For already 1000 PCS are made and assembled, there ist
no chance to make any hardware modifications. Even more, there is no room
left on the PCB to add any components and I also have no PIC pins left for
any batt voltage detection.
Now the 684 has an brown out reset, which is pricipally doing what I want,
but I see no possibility to distict between a "cold boot reset" (made when
e.g. batteries are changed) and brown out reset.
In case of a cold boot reset the devide should work normally, but when a
brownout occured, I'd like to simply disable any further operation until new
batteries are inserted.

Does anybody have an idea, know of any sort of "hidden features", any sort
of dirty tricks to make this?

Thanks for any help.

Peter

2011\10\10@041259 by Xiaofan Chen

face picon face
On Mon, Oct 10, 2011 at 4:00 PM, IB Peter Feucht <spam_OUTfeuchtsTakeThisOuTspamkabelbw.de> wrote:
> Now the 684 has an brown out reset, which is pricipally doing what I want,
> but I see no possibility to distict between a "cold boot reset" (made when
> e.g. batteries are changed) and brown out reset.
> In case of a cold boot reset the devide should work normally, but when a
> brownout occured, I'd like to simply disable any further operation until new
> batteries are inserted.
>
> Does anybody have an idea, know of any sort of "hidden features", any sort
> of dirty tricks to make this?
>

ww1.microchip.com/downloads/en/DeviceDoc/41202F-print.pdf
Section 12.3.7, Power Control (PCON) Register

The Power Control register PCON (address 8Eh) has
two Status bits to indicate what type of Reset occurred last.

Bit 0 is BOR (Brown-out). BOR is unknown on
Power-on Reset. It must then be set by the user and
checked on subsequent Resets to see if BOR = 0,
indicating that a Brown-out has occurred. The BOR
Status bit is a “don’t care” and is not necessarily
predictable if the brown-out circuit is disabled
(BOREN<1:0> = 00 in the Configuration Word
register).

Bit 1 is POR (Power-on Reset). It is a ‘0’ on Power-on
Reset and unaffected otherwise. The user must write a
‘1’ to this bit following a Power-on Reset. On a subsequent
Reset, if POR is ‘0’, it will indicate that a
Power-on Reset has occurred (i.e., VDD may have
gone too low).

-- Xiaofan

2011\10\10@044634 by Jan-Erik Soderholm

face picon face


Xiaofan Chen wrote 2011-10-10 10:12:
{Quote hidden}

Problem is, that if the PIC had e BOR due to "low batt", wount
the BOR logic hold the PIC in reset until the you have a
"non-low batt" condition ? That is, forever or until the
batt is replaced ?

I think that BOR will not work to monitor the batt voltage.

2011\10\10@073214 by Geo

picon face
Jan-Erik Soderholm wrote:


> Problem is, that if the PIC had e BOR due to "low batt", wount
> the BOR logic hold the PIC in reset until the you have a
> "non-low batt" condition ? That is, forever or until the
> batt is replaced ?

But this seems to meet the OP's requirement - do nothing until battery replaced?

quote:-
" but when a brownout occured, I'd like to simply disable any further operation until new batteries are inserted."

George Smit

2011\10\10@075638 by Jan-Erik Soderholm

face picon face
OK, fine then. :-)

I read it as some monitoring function where the PIC code
should take some action at "low battery" condition.

If not, it realy doesn't matter how to see the difference
between POR and BOR, since it will never "return" from
a brown-out anyway, not ?

Jan-Erik.




Geo wrote 2011-10-10 13:32:
{Quote hidden}

> George Smit

2011\10\10@092900 by Kerry Wentworth

flavicon
face
Looking at the data sheet, I see some interesting features.

Brownout can be enabled/disabled in software

The brownout threshold can be adjusted during programming

Brownout reset can be detected

So theoretically, you could bump up the brownout threshold to a value that would allow the PIC to continue operating for a while.  If a brownout is detected, leave brownout disabled and signal "low battery", otherwise enable brownout and operate normally. No hardware changes needed to implement this.

Kerry



IB Peter Feucht wrote:
{Quote hidden}

>

2011\10\10@113746 by Andre Abelian

picon face
Kerry,

How do you read brownout setting in software?

AA


________________________________
From: Kerry Wentworth <kwentworthspamKILLspamskunkworksnh.com>
To: Microcontroller discussion list - Public. <.....piclistKILLspamspam.....mit.edu>
Sent: Monday, October 10, 2011 6:27 AM
Subject: Re: [PIC:] Distinction between RESET and BOWNOUT

Looking at the data sheet, I see some interesting features.

Brownout can be enabled/disabled in software

The brownout threshold can be adjusted during programming

Brownout reset can be detected

So theoretically, you could bump up the brownout threshold to a value that would allow the PIC to continue operating for a while.  If a brownout is detected, leave brownout disabled and signal "low battery", otherwise enable brownout and operate normally. No hardware changes needed to implement this.

Kerry



IB Peter Feucht wrote:
{Quote hidden}

>

2011\10\10@115441 by Kerry Wentworth

flavicon
face
In software, you can only detect whether a brownout reset has occurred (PCON.0=0 if brownout reset occurred).  The threshold is set by programming the word at 2008h, which is only accessible to the PIC programmer.  It does not describe how the threshold varies with the value in 2008h, so some experimenting may be in order.

Kerry


Andre Abelian wrote:
{Quote hidden}

>>

2011\10\10@122302 by Michael Rigby-Jones

flavicon
face


{Quote hidden}

Make sure you check the datasheet for your part; the BOR peripheral takes a significant amount of current in most PIC's when it's enabled.  In the nano-watt devices the difference is especialy large e.g. ~1nA with it disabled, 1uA with it enabled.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\10\10@135301 by Andre Abelian

picon face
Kerry,

Brownout reset is directly connected to reset hardware and once it is enabled  it will reset the pic.

it is hard wire. the only thing you can do in software is disable/ enable. The voltage is set in configuration bits.
you can't sense and not allow to reset the pic like use it for battery indicator etc. "not going to work".
16f684 is low end pic not much you can do with it.

PCON.0 is status register you will know this bit is changed after reseting the pic
because of if this got set/clear it will reset the cheap.

Andre Abelian




________________________________
From: Kerry Wentworth <RemoveMEkwentworthTakeThisOuTspamskunkworksnh.com>
To: Microcontroller discussion list - Public. <spamBeGonepiclistspamBeGonespammit.edu>
Sent: Monday, October 10, 2011 8:53 AM
Subject: Re: [PIC:] Distinction between RESET and BOWNOUT

In software, you can only detect whether a brownout reset has occurred (PCON.0=0 if brownout reset occurred).  The threshold is set by programming the word at 2008h, which is only accessible to the PIC programmer.  It does not describe how the threshold varies with the value in 2008h, so some experimenting may be in order.

Kerry


Andre Abelian wrote:
{Quote hidden}

>>   

2011\10\10@153957 by Kerry Wentworth

flavicon
face
I can't say whether it will work or not, it would have to be tried.  But, the idea is that in the startup code, you look to see if the reason for the last reset was a brownout, or some other reason.  If it was a brownout, you know the battery is low.  This assumes that the battery has recovered enough to run the PIC.  It seems likely enough, since all outputs will be off after a brownout reset.  If you have seen a brownout, turn off brownout protection so you can continue to run, and indicate that the battery is running low.

Kerry


Andre Abelian wrote:
{Quote hidden}

>

2011\10\10@163735 by Andre Abelian

picon face
Kerry,

Cool. if they allow to reset the pic then it will work?
very nice job Kerry. 


In my project I save the reset cause in eeprom and
on reset I display it. I know its going to work CCS compiler

Andre


m: Kerry Wentworth <RemoveMEkwentworthTakeThisOuTspamspamskunkworksnh.com>
To: Microcontroller discussion list - Public. <EraseMEpiclistspamspamspamBeGonemit.edu>
Sent: Monday, October 10, 2011 12:38 PM
Subject: Re: [PIC:] Distinction between RESET and BOWNOUT

I can't say whether it will work or not, it would have to be tried.  But, the idea is that in the startup code, you look to see if the reason for the last reset was a brownout, or some other reason.  If it was a brownout, you know the battery is low.  This assumes that the battery has recovered enough to run the PIC.  It seems likely enough, since all outputs will be off after a brownout reset.  If you have seen a brownout, turn off brownout protection so you can continue to run, and indicate that the battery is running low.

Kerry


Andre Abelian wrote:
{Quote hidden}

2011\10\10@232645 by Sean Breheny

face picon face
Hi Peter,

This variable that you are talking about - will this be stored in
EEPROM/flash or RAM? I think that RAM contents may be destroyed during
a brown-out condition. Probably not, but I wouldn't rely on it.

It seems to me that others have already mentioned that there are
status bits in the PIC which will tell you whether the last reset was
a power-on reset or a brown-out condition. Why not simply check for
this at every boot and if it was a brown-out reset, then do not
operate. Replacing the batteries will cause a power-on reset instead
and then you can resume normal operation.

Sean


On Mon, Oct 10, 2011 at 9:26 AM, IB Peter Feucht <EraseMEfeuchtsspamEraseMEkabelbw.de> wrote:
{Quote hidden}

>

2011\10\11@041418 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: @spam@piclist-bounces@spam@spamspam_OUTmit.edu [spamBeGonepiclist-bouncesspamKILLspammit.edu] On
Behalf
{Quote hidden}

Even better if you can do something to cause a high current demand at
start-up so you get a brown out before the main code starts executing.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\10\17@050326 by Peter

picon face
IB Peter Feucht <feuchts <at> kabelbw.de> writes:
> I developped a small battery operated device, using a 16F684, everything
> works fine. Now the customer shows up, and wants to have any sort of
> batt-low indication. For already 1000 PCS are made and assembled, there ist

You can use statistics to determine if the BORs are becoming too frequent (a
sign for low battery). It works like so:
- A new battery may cause BORs at turn on and turn off, several even. Let's call
this number of BORs N1, say, 3. Also, they will occur during the 'turn on' or
'turn off' phase, which you can account for with a state machine in the software.
- A weak battery will cause BORs every now and then, when external loads are
connected especially. They will occur in normal operation (not when starting and
stopping, see above state machine). Let's call this new number of BORs N2, which
will normally be way bigger than 3, but let's say 5 for now.
- If any of your comparator or ADC inputs depend on battery voltage directly you
can change your code to 'measure' battery voltage using those.

Now you can implement a state machine like:

if( ResetOccurredByBor() && (State != ST_STOP) ) {
 // do not count BORs when stopping power - assumes mcu can turn its
 // own power off in some way
 IncrementNumBors();
}
if( UserPressedNumBorReset() ) { // start fresh cycle, hope batteries are new
 SetNumBors(0);
 SetLockout(0);
 while( UserPressedBorReset() ); // wait ...
}
tmp = GetState();
if( (t == ST_START) || (t == ST_STOP) ) {
 if( GetNumBors() > MAX_N1 ) SetLockout(2); // most severe, battery very weak
or bad contacts
} else {
 if( GetNumBors() > MAX_N2 ) SetLockout(1); // likely weak battery, resets in
mid-operation, }
switch( GetLockout() ) {
 case 0: ; // all is well, operate normally
   break;
 case 1: ; // battery may be low, turn on low battery ind., try to work
   break;
 case 2: ; // we don't want to work at all, battery end ind., loop forever
   lockout: goto lockout;
}
     Where Lockout is a variable you set which shuts down the device (or makes it in-operable and indicates low battery). You can even set the Lockout bit in
EEPROM so it will require a device reset on battery change from the user
(pushing a specified button, not the reset mcu signal). The State and NumBors
variables above should me located in a place that is not wiped by RESET (usually
RAM assuming the mcu always has power and is sleeping between active uses), and
if you use a C compiler be sure to edit the startup code so those locations are
really left alone during initialization, if your compiler's startup code wipes
all ram by default.

You can refine this by having additional steps of NumBors > LOW_N1 etc to
indicate imminent battery failure.

And, yes, this is a hack, unless you have comparator or ADC information about
something directly related to battery state, but you have 1000 products and your
good name (?) to save.

<aside>I "love" people who come back after 5 years for added features they
definitely decided they do not want, in despite of having been explained why
that may be needed 5 years before. Such as 10 cents for a flash upgrade
connector or 2 cents for a pin to be able to attach a serial terminal and debug
or reprogram via boot loader or similar.</aside>

-- Peter

2011\10\17@065309 by alan.b.pearce

face picon face
> <aside>I "love" people who come back after 5 years for added features they
> definitely decided they do not want, in despite of having been explained why
> that may be needed 5 years before. Such as 10 cents for a flash upgrade
> connector or 2 cents for a pin to be able to attach a serial terminal and debug
> or reprogram via boot loader or similar.</aside>

You mean you didn't implement it anyway, and then sell them an expensive plug on connector and cable 5 years later ... ???


-- Scanned by iCritical.

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