 |
 |
| View previous topic :: View next topic |
| Author |
Message |
evsource
Joined: 21 Nov 2006
Posts: 129
|
| Another restart_cause() always NORMAL_POWER_UP |
 Posted: Thu Jul 22, 2010 1:12 pm |
 |
|
I'm using a 18f14k22 w/ V4.109 PCH compiler. Chip is running on 5V, with heavy ground planes, bypass capacitors, etc. I have the watchdog timer turned off, no MCLR, and NOBROWNOUT.
At some points in the execution of the code, I get a reset about every 100ms. The cause is always NORMAL_POWER_UP. I have the restart_cause() function running before anything else is executed in code.
The list file says the following:
ROM used: 1164 bytes (7%)
Largest free fragment is 15220
RAM used: 41 (8%) at main() level
47 (9%) worst case
Stack: 2 locations
Anyone care to take a stab at why I would always get NORMAL_POWER_UP when it's resetting? I've monitored the power supply when this happens, and it's very nice and steady at 5V. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jul 22, 2010 1:33 pm |
|
|
Can you duplicate the problem with just a short test program that only
contains the restart cause code and a printf to show the results ?
If so, post that program. (with the #include, #fuses, #use delay, etc). |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Thu Jul 22, 2010 2:02 pm |
|
|
| PCM programmer wrote: | Can you duplicate the problem with just a short test program that only
contains the restart cause code and a printf to show the results ?
If so, post that program. (with the #include, #fuses, #use delay, etc). |
I knew you'd ask. I almost always post a simplified program showing the problem, but in this case, it would be difficult to duplicate the scenario without the hardware setup.
It's a control application with multiple PICs talking to each other. The PIC in question receives a command from another chip, then controls an output with a PI control loop. Something funky is going on with the variable that accumulates the error. When I add the NOSTVREN fuse, I don't get the reset. What bothers me is why do I get the NORMAL_POWER_UP result if something else is causing the reset? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jul 22, 2010 2:16 pm |
|
|
Post the first part of your program where you check the restart cause.
Post the #include, #fuses, #use delay, etc.
Basically, I want to see if you are checking the restart cause as the
very first thing you do in main(), or do you perform a lot of other
actions before checking it.
Also I want to look at your #fuses for any anomalies.
Also, do you do anything unusual in your code, such as using #org,
#build, #separate, etc. Anything that alters the way the compiler
builds the program. |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Thu Jul 22, 2010 2:25 pm |
|
|
| PCM programmer wrote: | Post the first part of your program where you check the restart cause.
Post the #include, #fuses, #use delay, etc.
|
Okay. All I've stripped out is a bunch of #defines and the function declarations. I'm running the program right now with the #use fast_io(ALL) commented out. Looks like my NOSTVREN fuse isn't preventing the resets afterall.
| Code: | #include <18f14k22.h>
#device ADC=10 // use 10 bit ADC reading
#fuses INTRC,PLLEN,NOWDT,NOMCLR,NOWDT,NOBROWNOUT,NOLVP,NOPUT,NOSTVREN
#fuses NOPROTECT,NOCPD,NOCPB,NOWRT,NOWRTD,NOWRTB,NOWRTC,NOEBTR,NOEBTRB
#use delay(clock=64000000)
//#use fast_io(ALL)
void main() {
if(restart_cause() == NORMAL_POWER_UP) output_high(PIN_C0);
else output_low(PIN_C0);
setup_oscillator(OSC_64MHZ | OSC_PLL_ON);
|
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jul 22, 2010 2:31 pm |
|
|
My first thought is to get rid of the PLL. Run it at 8 MHz. See what
happens.
Also, read my post above. I was adding some comments that you
may have missed. |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Thu Jul 22, 2010 2:59 pm |
|
|
| PCM programmer wrote: | My first thought is to get rid of the PLL. Run it at 8 MHz. See what
happens.
|
No change. Still same restart cause. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jul 22, 2010 4:21 pm |
|
|
I looked at the .LST file for the reset cause code, and I didn't see
anything wrong with it for your version of the compiler.
I think you need to determine if the problem is in hardware or software.
If software, is it a coding problem or a compiler bug ?
First I would make a simple program with the restart cause code,
and then have it sit in a while loop that blinks an LED. If it works
(i.e., doesn't reset) it's likely that the hardware is OK. If not, then
try a different PIC. Try a pin-compatible PIC that's not in the K-series.
Look closely at all external components and board layout. Check the
power supply very carefully.
If the hardware is OK, you can begin to look at the software. First I would
back off on anything that "pushes" the compiler. This means remove any
directives that cause the compiler to do things differently than normal,
such as #separate, #build, #org, #reserve, anything of that sort.
Then I would start to comment out blocks of code. Reduce the
functionality of the program piece by piece to see if it improves.
Stop using interrupts. Dummy up routines, so that most code is not
executed inside the routine, but instead the routines will just return
a nominal value (a constant) that will still allow the program to work.
In other words, if you can't see the problem by inspection, then disable
portions of the program until you get it work without resetting.
Also, what does this PIC do ? Is this possibly a high-current motor
driver board ? Or does it drive anything that switches current, such
as relays ? And what's the static electricity environment ? |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Thu Jul 22, 2010 5:04 pm |
|
|
| PCM programmer wrote: |
I think you need to determine if the problem is in hardware or software.
If software, is it a coding problem or a compiler bug ?
|
Yeah, that's what I'm working on.
| PCM programmer wrote: |
First I would make a simple program with the restart cause code,
and then have it sit in a while loop that blinks an LED. If it works
(i.e., doesn't reset) it's likely that the hardware is OK. If not, then
try a different PIC. Try a pin-compatible PIC that's not in the K-series.
|
I haven't had very good luck with this PIC in general. The SPI stuff took a day to get working. When I upgraded to the newest version of compiler, it worked immediately.
The errata shows a lot of bugs. One is related to resets. However, they are with low temperatures. That's certainly not the case here! But, there could be something related. I think I'm going to try a pin-compatible PIC to see if that might solve the problem. Time to start the process of elimination.
| PCM programmer wrote: |
Also, what does this PIC do ? Is this possibly a high-current motor
driver board ?
|
That's what it is. It's a nasty environment. This is a new revision using a new PIC. There's a second PIC located physically right next to this one, and it doesn't have any problems. So I don't think it's related to the power supply or layout. It's either something in software resetting it, or a fluke with the chip.
Thanks for the tips. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Fri Jul 23, 2010 4:16 am |
|
|
Or, something the chip is connected to, that the other is not.
Classic thing in this sort of environment, would be (for example), lacking the right trap diodes, so that some of the induced flyback voltage routes through the chip driving a transistor. Though most of the time this will simply destroy the chip, if the energy is not too great, it can simply result in a reset. Restart_case, does not have a value for "oh dear, I've been spiked".....
Best Wishes |
|
|
|
|
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
