 |
 |
| View previous topic :: View next topic |
| Author |
Message |
RickDaystorm
Joined: 01 Jul 2012
Posts: 12
|
| PIC18F67K22 won't run on power up [SOLVED] |
 Posted: Tue Oct 14, 2014 7:10 pm |
 |
|
I've used the 18F6722 before without any issues, but I'm having a silly problem with the 18F67K22 where it will only run following the loading of the program below with the ICD, but it won't run on power up. It seems to crash at the first delay_ms(100) statement. I am sure it has something to do with my fuse settings (as they pertain to the oscillator set up perhaps), but I can't seem to figure out what.
Any suggestions are much appreciated.
During programming I see the LED flashing at a much faster rate almost as though it starts to run the program with the wrong oscillator setting (although I'd expect to see the LED turned off during programming) and once it locks up I can get it to start up by unplugging the ICD from a USB port on the PC (which typically puts the PIC in reset - or it used to on older versions of the ICD). What's strange about that is I have a fuse that should cause the MCLR pin to be ignored, so I am not sure how the unplugged ICD is managing to reset the PIC.
The PIC will also start running if I touch PIN 7 with the multimeter probe, but according to my fuse settings it's supposed to be ignoring the MCLR pin altogether.
This PIC is running on a 5V board with an external 40MHz powered oscillator (CB3-3C-40M0000). I am using PCH v4.137 with an ICD-U64.
Pin 7 (nMCLR/G5) is tied to Pin 1 on the ICD connector through a 100Ohm resistor. Pin 1 on the ICD connector also goes to 5VD through a 47K resistor and to GND through a 0.1uF capacitor (which is not populated on the board). I am measuring 3.967V at the Pin 1 of the ICD and at the Pin 7 of the PIC.
The power up is clean and glitch free (Pin 7 voltage rises from 0.7V to 5V over 3ms in a steady and monotonic fashion which is the same as the PICs VDD rail given that the 0.1uF cap has been removed from Pin 1 of the ICD connector), but I'm still using a Power-Up-Timer and a 3.0V brownout - just to be safe. The PIC locks up with or without these fuses enabled.
Here is my code
| Code: |
#include <18F67K22.h>
#device adc=12
#FUSES NOWDT //No Watch Dog Timer
#FUSES ECH_IO //External clock
#FUSES NOPLLEN //4X HW PLL disabled, 4X PLL enabled in software
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES PUT //Power Up Timer
#FUSES BROWNOUT
#FUSES BORV30 //Brownout reset at 3.0V
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOSTVREN //Stack full/underflow will not cause reset
#FUSES NODEBUG
#FUSES NOPROTECT
#FUSES NOCPB
#FUSES NOCPD
#FUSES NOWRT
#FUSES NOWRTC
#FUSES NOWRTB
#FUSES NOWRTD
#FUSES NOEBTRB
#use delay(clock=40000000)
#use rs232(baud=2400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=RS232_UART,errors)
#use rs232(baud=9600,parity=N,xmit=PIN_G1,rcv=PIN_G2,bits=8,stream=RS485_UART,errors)
// Pin Defines
#define STATUS_LED PIN_B4
int TIMER1_TICKS = 0;
// FUNCTION PROTOTYPES
void micro_init();
// INTERRUPTS
#int_TIMER0
void TIMER0_isr(void)
{
}
#int_TIMER1
void TIMER1_isr(void)
{
if(TIMER1_TICKS == 255) TIMER1_TICKS = 0;
TIMER1_TICKS++;
}
#int_TIMER2
void TIMER2_isr(void)
{
}
#int_RDA
void RDA_isr(void)
{
}
/*
#int_TBE
void TBE_isr(void)
{
}*/
#int_RDA2
void RDA2_isr(void)
{
}
/*
#int_TBE2
void TBE2_isr(void)
{
}*/
void main()
{
micro_init();
while(TRUE)
{
output_high(STATUS_LED);
delay_ms(100);
output_low(STATUS_LED);
delay_ms(100);
}
while(1);
}
void micro_init()
{
setup_adc_ports(sAN0|sAN1|sAN2|sAN3|sAN4|sAN5|sAN6|sAN7|sAN8|sAN9|sAN10|sAN11,VREF_VREF);
setup_adc(ADC_CLOCK_DIV_4);
//setup_adc(ADC_CLOCK_DIV_4|ADC_TAD_MUL_16);
set_adc_channel(0);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_2);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_8);
setup_timer_2(T2_DIV_BY_16,255,16);
setup_timer_3(T3_DISABLED | T3_DIV_BY_1);
setup_timer_4(T4_DISABLED,0,1);
setup_timer_5(T5_DISABLED | T5_DIV_BY_1);
setup_timer_6(T6_DISABLED,0,1);
setup_timer_7(T7_DISABLED | T7_DIV_BY_1);
setup_timer_8(T8_DISABLED,0,1);
setup_timer_10(T10_DISABLED,0,1);
setup_timer_12(T12_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
output_low(STATUS_LED);
//enable_interrupts(INT_TIMER0);
//enable_interrupts(INT_TIMER1);
//enable_interrupts(INT_TIMER2);
//enable_interrupts(INT_TIMER3);
enable_interrupts(INT_RDA);
//enable_interrupts(INT_TBE);
enable_interrupts(INT_RDA2);
//enable_interrupts(INT_TBE2);
enable_interrupts(GLOBAL);
} |
Last edited by RickDaystorm on Tue Oct 14, 2014 7:51 pm; edited 1 time in total |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Tue Oct 14, 2014 7:30 pm |
|
|
You have enabled serial interrupt without anything in the serial interrupt handlers to clear the interrupts. Naturally it is going to crash.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
RickDaystorm
Joined: 01 Jul 2012
Posts: 12
|
|
| Posted: Tue Oct 14, 2014 7:50 pm |
|
|
Thanks for the quick response asmallri.
That was definitely embarassing, especially given that I'd just spent hours ruining nearly all nMCLR-related passives on this board.
I disabled those serial interrupts and the program now runs perfectly well on each power-up.
Rick |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Tue Oct 14, 2014 8:03 pm |
|
|
| RickDaystorm wrote: | Thanks for the quick response asmallri.
That was definitely embarassing, especially given that I'd just spent hours ruining nearly all nMCLR-related passives on this board.
I disabled those serial interrupts and the program now runs perfectly well on each power-up.
Rick |
We all have our bad days :-)
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19551
|
|
| Posted: Wed Oct 15, 2014 12:59 am |
|
|
Yes.
This is one of those ones, that every single person here who has worked with code/hardware for any length of time, will have encountered at some point.
You get 'hooked' on where you think the problem is, go round in little circles, looking at this, and miss something that should be obvious, or should at least be checked.....
I've said in other threads, that the only way to sometimes find this type of thing, is to 'step away' and do something completely unconnected. Things like mowing the lawn, chopping logs, doing a bike ride etc., then often when you return there is the sudden 'oh' moment. 
I talk about "wall, head, impact technology testing".
Nice quick spot from Asmallri. |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Wed Oct 15, 2014 12:49 pm |
|
|
The other problem solving method that often works quite well is to explain the problem to someone else in detail (even if they don't understand what you are saying). Often, halfway through the explanation, you have one of those "duh ... never mind" moments where it all becomes obvious. 
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
|
|
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
