Searching \ for '[PIC] Heavy Power Cycling Application: strange res' 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/power.htm?key=power
Search entire site for: 'Heavy Power Cycling Application: strange res'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Heavy Power Cycling Application: strange res'
2006\10\04@110843 by Bob Axtell

face picon face
I'm getting some strange results with an application that powers on/off
a low-end PIC repeatedly (about once per second): the EEPROM
is getting scrambled randomly.

The application reads something out of the EEPROM and sends data
out. All signal and power lines are clamped with low-voltage varistors
and the power is applied from another PIC several feet away. Yet before
the night is over, the EEPROM is scrambled.  Yes, there IS code to
write to EEPROM in the data space, but it is never actuated, in fact has
been prevented from writing to the EEPROM..

It seems that the device is powering up and running out of the wrong data
space. The device is a PIC12F629 in SOIC8. The code simulates perfectly
(never jumps to wrong area in MPLAB 7.41) and  otherwise works perfectly.
Uses config: internal RC, WDT ON, Pwrup Timer ON, Brwn OFF, Mclr EXT
(but has 22K pullup).

Anybody ever seen anything like this before? I am very perplexed...

--Bob

2006\10\04@112435 by M. Adam Davis

face picon face
You have brownout off.  Do you have a low voltage reset in the
circuit?  How is powered exactly (close regulator with filtering and
caps, or just a long line to the power source)?

Jumping to random points in code indicates to me that the device is
not being properly powered or reset.  Perhaps the power up reset timer
isn't long enough, and it's running on low voltage in the beginning.
Perhaps it's still trying to run on low voltage when the power goes
out at one end of the line, but local caps are slowly draining.

I'd put in an external brownout reset device to eliminate this as a
possibility if you can't turn on the local brownout reset.

-Adam

On 10/4/06, Bob Axtell <spam_OUTengineerTakeThisOuTspamneomailbox.com> wrote:
{Quote hidden}

> -

2006\10\04@113006 by Harold Hallikainen

face
flavicon
face
Can you turn on the brownout protect? Maybe the processor is going wild as
the power goes down?

Harold

{Quote hidden}

> -

2006\10\04@114638 by John Temples

flavicon
face
It doesn't sound like you have any brownout protection.  During a
brownout, the PIC is running but RAM is scrambled: this means the PC
can contain a random address, and execution can jump into the middle
of your EEPROM write code.

On Wed, 4 Oct 2006, Bob Axtell wrote:

{Quote hidden}

> --

2006\10\04@120101 by Alan B. Pearce

face picon face
> I'm getting some strange results with an application that powers on/off
> a low-end PIC repeatedly (about once per second): the EEPROM
> is getting scrambled randomly.

Why power it off, why not go to sleep mode, and restart from an interrupt?

2006\10\04@120317 by Bob Axtell

face picon face
Harold Hallikainen wrote:
> Can you turn on the brownout protect? Maybe the processor is going wild as
> the power goes down?
>  
I think you guys might be right. I've never used brownout detect before.
Maybe I need to here. The system
normally runs at 5V but I have one situation where it needs to run at
3.3V. So I set it to the lower bandgap?

The power source is another PIC. There is a 100nF cap at the F629 for
filtering, and maybe since the driving
PIC can't deliver more than 25mA,  the risetime is too slow.  This is
PROBABLY the source of the problem,
and brownout detect might fix it.

Thanks, guys.

--Bob
{Quote hidden}

>> --

2006\10\04@120530 by Bob Axtell

face picon face
M. Adam Davis wrote:
> You have brownout off.  Do you have a low voltage reset in the
> circuit?  How is powered exactly (close regulator with filtering and
> caps, or just a long line to the power source)?
>  
Its a long line, but being driven by another PIC limits the risetime.

Actually, I _CAN_ turn on brownout detect. I'll try it.


> Jumping to random points in code indicates to me that the device is
> not being properly powered or reset.  Perhaps the power up reset timer
> isn't long enough, and it's running on low voltage in the beginning.
> Perhaps it's still trying to run on low voltage when the power goes
> out at one end of the line, but local caps are slowly draining.
>  
I think that's it.

Thanks!

--Bob

{Quote hidden}

>> --

2006\10\04@123422 by Bob Axtell

face picon face
Alan B. Pearce wrote:
>> I'm getting some strange results with an application that powers on/off
>> a low-end PIC repeatedly (about once per second): the EEPROM
>> is getting scrambled randomly.
>>    
>
> Why power it off, why not go to sleep mode, and restart from an interrupt?
>  
It can get disconnected as well. But I have good supressors for that...

I think I just need to use the brownout detect.

--Bob

2006\10\04@150953 by Bob Axtell

face picon face
Bob Axtell wrote:
> Alan B. Pearce wrote:
>  
>>> I'm getting some strange results with an application that powers on/off
>>> a low-end PIC repeatedly (about once per second): the EEPROM
>>> is getting scrambled randomly.
>>>    
>>>      
>> Why power it off, why not go to sleep mode, and restart from an interrupt?
>>  
>>    
> It can get disconnected as well. But I have good supressors for that...
>
> I think I just need to use the brownout detect.
>
> --Bob
>  
Status: 2 hrs of testing, no errors. I only changed the Brownout Detect
at LOW bandpass setting,
or about 7500 tries..

--Bob

2006\10\04@182507 by Bob Axtell

face picon face
Bob Axtell wrote:
{Quote hidden}

Now 4.5 hrs, solid operation without errors. Wow, that brownout detector
really IS useful after all.
I always used the  powerup timer, but the brownout detector is needed to
solve very slow powerup/powerdown
risetimes. About 20000 cycles without an error.

--Bob

2006\10\04@213007 by Gerhard Fiedler

picon face
Bob Axtell wrote:

> Now 4.5 hrs, solid operation without errors. Wow, that brownout detector
> really IS useful after all. I always used the  powerup timer, but the
> brownout detector is needed to solve very slow powerup/powerdown
> risetimes. About 20000 cycles without an error.

I always have it on. So far I haven't had an application where it would
hurt. Has anybody some ideas what would be applications where you don't
want the brownout detector?

Gerhard

2006\10\04@214844 by Brent Brown

picon face
> > Now 4.5 hrs, solid operation without errors. Wow, that brownout
> > detector really IS useful after all. I always used the  powerup
> > timer, but the brownout detector is needed to solve very slow
> > powerup/powerdown risetimes. About 20000 cycles without an error.
>
> I always have it on. So far I haven't had an application where it
> would hurt. Has anybody some ideas what would be applications where
> you don't want the brownout detector?

One case is battery backup. Eg. the PIC normally runs at 5V then falls back to
battery, say 3.6V (which is lower than the brownout point), and if you want it to keep
running the brownout detector must be disabled. Kind of obvious, but handy to know
before you need it.

Also, in very low power apps. At least in the older PIC's enabling brownout (and/or
watchdog for that matter) would add 10's or 100's of micro amps (can't remember
figures). The newer "nanoWatt" devices I think are quite a lot better in this regard.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  brent.brownspamKILLspamclear.net.nz


2006\10\04@214948 by John Temples

flavicon
face
On Wed, 4 Oct 2006, Gerhard Fiedler wrote:

> Has anybody some ideas what would be applications where you don't
> want the brownout detector?

When you're running on batteries and you care about battery life; BOR
pulls a lot of current.  Some newer PICs can disable BOR during sleep
automatically, which helps.

--
John W. Temples, III

2006\10\04@233745 by Bob Axtell

face picon face
Gerhard Fiedler wrote:
> Bob Axtell wrote:
>
>  
>> Now 4.5 hrs, solid operation without errors. Wow, that brownout detector
>> really IS useful after all. I always used the  powerup timer, but the
>> brownout detector is needed to solve very slow powerup/powerdown
>> risetimes. About 20000 cycles without an error.
>>    
>
> I always have it on. So far I haven't had an application where it would
> hurt. Has anybody some ideas what would be applications where you don't
> want the brownout detector?
>
> Gerhard
>
>  
I rarely have an application where the VDD rise/fall time was slow. In a
typical application, the VDD
is so loaded down that the device VDD drops like a rock, and the supply
impedance is so low that risetime
is very fast. Even so, I always used the powerup timer.

I guess it never hurts in any case. I thought about it earlier, but
since this can run at 3.3V as well as 5V, I
figured it might interfere, but in fact it doesn't.

What a lesson.

--Bob

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