 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mvanvliet
Joined: 02 Jun 2009
Posts: 123
Location: The Netherlands
|
| Random reset 16F1503 |
 Posted: Mon Jul 10, 2017 4:24 am |
 |
|
With the newer controllers like the 16F1503, 12F1501 and 16F1824 we have the problem that they reset randomly because of disturbing (ESD for example).
Is it more common because of the "extra low power/XLP" function?
Are more people expecting these resets and how to solve them? I've tried an 100nF capacitor directly over power pins, but didn't solve the problem.
| Code: |
#include "config.c"
int RUN_counter=0, EMPTY_fault_counter=0, OCP_fault_counter1=0, OCP_fault_counter2=0, UVP_fault_counter=0;
int I_sense1=0, U_sense1=0, U_VHP=0, U_start=0;
short PSU_OK = 1, RS232_ENABLED = 0;
long i=0, EXTRA_counter=0;
int j=0, k=0;
int timer0 = 0;
int I_sense[32] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
long I_sense_array = 0;
int I_sense_average = 0;
int U_sense[32] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
long U_sense_array = 0;
int U_sense_average = 0;
int U_sense_extra = 0;
int beep_CH1 (int z);
int beep_CH2 (int y);
void main()
{
SETUP_WDT(WDT_OFF | WDT_512MS);
setup_oscillator(OSC_1MHz);
setup_comparator(NC_NC_NC_NC);
setup_dac(DAC_OFF);
//SETUP_DAC(DAC_VSS_VDD|DAC_OUTPUT1); // 5bit DAC dus od tot 31d en dan begint de uitgang weer bij opnieuw op te lopen.
//DAC_WRITE(16); // DAC uitgang is VDD/32*16
setup_adc_ports(sAN3|sAN6|sAN7|VSS_VDD);
//setup_adc_ports(sAN3|sAN4|sAN6|sAN7|VSS_VREF); //VREF als externe ingang werkt maar trekt wel beetje stroom naar binnen.
setup_vref(VREF_OFF | VREF_COMP_DAC_OFF | TEMPERATURE_INDICATOR_DISABLED);
setup_adc(ADC_CLOCK_DIV_2); // Built-in A/D setup function TAD is 2µSec
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_64); // 1.000.000/4/64 = 66mSec tot overflow 8-bit register.
PORT_a_PULLUPS(0x2B); // 101011 (1=enabled) 5 4 3 2 1 0
PORT_c_PULLUPS(0x00); // 000000 (1=enabled) 5 4 3 2 1 0
status_bits=0; // Enable, Error, Run, UVP, OCP1, OCP2, Nop, Nop
output_low (DTA); //Hardware check/OCP check
output_low (PIN_C5); //In geval dat je PWM uit zet want dan gaat de uitgang als digitale poort verder.
output_high (PIN_C1); //In geval dat je PWM uit zet want dan gaat de uitgang als digitale poort verder.
set_pwm1_duty (0); // Q1 mosfet
set_pwm3_duty (0); // Q2 mosfet
set_pwm4_duty (0); // Opto coupler
setup_timer_2(T2_DIV_BY_1, 99, 1); // 1.000.000/4/1/99 = 2500hz (met 99 dus 0-400 duty cycle).
//setup_pwm1(PWM_ENABLED | PWM_OUTPUT); // Configure PWM1 for Q1
setup_pwm3(PWM_ENABLED | PWM_OUTPUT); // Configure PWM1 for Q2
setup_pwm4(PWM_ENABLED | PWM_OUTPUT | PWM_ACTIVE_LOW); // Configure PWM4 for opto
DISABLE_INTERRUPTS(PERIPH); //
DISABLE_INTERRUPTS(GLOBAL);
output_toggle (DTA);
delay_ms(1000);
if (!input(MCLR))
{
RS232_ENABLED = 1;
}
while (1)
{
////////////////////////////// MAIN LOOP //////////////////////////////////////
while (PSU_OK==1)
{
output_toggle (DTA);
if(Input(Input1) == 1)
{
output_high(Output1);
//set_pwm1_duty(400); // Q1 100% duty
}
else
{
output_low(Output1);
//set_pwm1_duty(0); // Q1 100% duty
}
}
}
} |
config.c:
| Code: | #include <16F1503.H>
#FUSES INTRC_IO, NOMCLR, PROTECT, WDT_SW, PUT, BROWNOUT,BORV25, NOLPBOR, STVREN, NOLVP
#Device ADC=8 //8 bit
#use delay(clock=1000000) //Fuses and delay are set, so int osc is set at 4Mhz.
#ignore_warnings 203
#use rs232(baud=2400, xmit=PIN_A5, ERRORS) // Debug pin for RS232
#define DTA PIN_A0 // Input Digital AN0
//#define CLK PIN_A1 // Input Digital AN1
//#define PWM2 PIN_A2 // Output Digital PWM3
#define MCLR PIN_A3 // Input Digital
//#define U_VHP PIN_A4 // Input Analog AN3
//#define Debug PIN_A5 // Input Digital
#define Input1 PIN_C0 // Input Analog AN4
//#define Info_out PIN_C1 // Output Digital AN5 PWM4
//#define U_DC PIN_C2 // Input Analog AN6
//#define I_IN1 PIN_C3 // Input Analog AN7 PWM2
#define Input2 PIN_C4 // Output Digital
#define Output1 PIN_C5 // Output Digital PWM1
#byte APFCON=getenv("SFR:APFCON")
#bit SDOSEL = APFCON.5
#bit SSSEL = APFCON.4
#bit T1GSEL = APFCON.3
#bit CLCSEL = APFCON.1
#bit NCO1SEL = APFCON.0
#bit TMR0IF = getenv("BIT:TMR0IF") // TMR0 counter overflow 00Bh, bit2
#bit TMR1IF = getenv("BIT:TMR1IF") // TMR1 counter overflow 0011h, bit0
#bit T1GGO_DONE = getenv("BIT:T1GGO") // TMR1 Go/done bit 0019h, bit3
#bit TMR1GIF = getenv("BIT:TMR1GIF") // TMR1 interrupt 0011h, bit7
#bit T1GVAL = getenv("BIT:T1GVAL") // TMR1 GATE VAL 0019h, bit2
#define RUN_time 255 // time is 12.75 Sec
#define EMPTY_time 15 // time is 0.75 Sec
#define UVP_time 1 // time is 0.05 Sec
#define OCP1_time 100 // time is 5.0 Sec (was 80 en 4.0sec)
//#define OCP2_time 10 // time is 0.5 Sec
#define OCP2_time 3 // time is 0.15 Sec (+0sec, -0.05sec)
//Define ADC channels
#define U_VHP_ADC 3
#define U_sense1_ADC 6
#define I_sense1_ADC 7
int status_bits; // Error, Empty, Run, UVP, OCP1, OCP2, Nop, Nop
#bit ERROR_BIT = status_bits.7
#bit EMPTY_BIT = status_bits.6
#bit RUN_BIT = status_bits.5
#bit UVP_BIT = status_bits.4
#bit OCP_BIT1 = status_bits.3
#bit OCP_BIT2 = status_bits.2
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Mon Jul 10, 2017 5:05 am |
|
|
There are several possible hardware reasons for random resets
1) bad PCB design where
traces are too close to each other
trace routing
poor grounding
2) unterminated I/O pins. ALL should be pulled high or low
3) mech switches/ push buttons without debounce caps
4) improper 'earth' or grounding
5) no shielding if using plastic box for project
6) not enough bypass caps. Every chip needs one PLUS 1 every 2sq in of PCB
I see 'PWM ' being used. If this is drawing ANY amount of power, PCB traces MUST be thick (wide) and PSU MUST be capable of 5-10X the current demand of the 'load'. Even a small 'dip' in the Vdd could send an EMP to the PIC causing reset.
Other things that cause random resets...welders, cell phones, CFLs, etc.
I have to admit tracking down WHAT is causing 'random resets' can be frustrating and generally it's a process of elimination. Make a list, do 'A', test, if still fails do 'B', test... repeat until it works...If lucky this only takes a day or two. With one project it took me 2 1/2 MONTHS.
good luck
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jul 10, 2017 10:37 am |
|
|
If you can't solve the problem, then post an in-focus hi-res photo of your
board. Preferably not a cell phone camera. Use a better camera. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Tue Jul 11, 2017 7:05 am |
|
|
Generally, the lower the operating voltage of a chip, the lower the noise margin. If (for instance), you have inputs with Vil at 0.6v, and Vih at 0.5Vdd (say), then a 5v chip has 1.9v between the two thresholds, while a 3.3v chip only has 1.05v between the same thresholds.
Good design becomes ever more important.
My current prototype, has a switch mode 5v rail (from 24v), then a linear regulator to 3.3v. A total of 14 capacitors on the 3.3v supply. Low ESR ceramic capacitors adjacent to each supply pin on the processor, then ones by each major chip. A ground plane on the bottom of the board, 3.3v plane on the top. 99% of the tracking is on the inner two layers. It's already passed EMC testing both for it's own radiation, and surviving external signals. The biggest currents are on the 5v and 24v sections.
You need always to think where energy goes, what will stop it, and the paths the current will take.
One of the tests we put kit through, has a 250000v generator giving a arc simulation of a nearby lightning strike. You learn to design carefully when you have to be able to keep running when this happens... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Tue Jul 11, 2017 8:54 am |
|
|
As a further comment.
Read 'restart_cause' at the start of the code.
Output this somehow.
The nature of the reset will help tell you what is actually happening. |
|
|
mvanvliet
Joined: 02 Jun 2009
Posts: 123
Location: The Netherlands
|
|
| Posted: Wed Jul 12, 2017 2:48 am |
|
|
| Thanks for all the answers. We tried the reset_cause in the past but it was mentioned as an "NORMAL_POWER_UP". |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Wed Jul 12, 2017 3:37 am |
|
|
OK.
First, where are you reading the restart_cause?. It should be about the first thing in your main code. The result does get changed if you do anything like configure the watchdog, so it needs to be before any such instructions.
Assuming it was right at the start, then it tells you a lot. It rules out a brownout, a stack overflow or a watchdog for example.
Normal power up, actually implies that the power rail has dropped below the POR reset point. Nothing else. It only needs to do this for a tiny time.
However it is worth realising that this will be what the chip shows if there has been for example a code error, resulting in a jump to address 0, then the restart_cause will show 'normal power up'. |
|
|
|
|
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
