View previous topic :: View next topic |
Author |
Message |
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
Trouble with PIC18F24K22 |
Posted: Tue Jul 24, 2012 10:50 am |
|
|
I'm having trouble getting a PIC18F24K22 to operate. It seems like the oscillator is not running since I can not get any of the pins to toggle with the most basic code.
Thanks,
MotoDan
Code: |
#include <18F24K22.h>
#fuses INTRC_IO, NOWDT, BROWNOUT, PUT, NOLVP, NODEBUG
#use delay(clock=16M)
//======================================
void main(void)
{
while(1)
{
output_high(PIN_A7);
delay_ms(10);
output_low(PIN_A7);
delay_ms(10);
}
}
|
|
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Tue Jul 24, 2012 11:07 am |
|
|
I was finally able to get a pin to toggle. Had to change the Fuses. Can someone explain why the fuse change made the difference? Also added code to set the osc to 16M. The part worked prior to adding this, but the osc freq was not 16M as expected.
Code: |
#include <18F24K22.h>
#fuses NOWDT,PROTECT,BROWNOUT,PUT,NODEBUG,NOCPD,NOCPB,NOMCLR
#use delay(clock=16M)
//======================================
void main(void)
{
setup_oscillator(OSC_16MHZ|OSC_NORMAL);
while(1)
{
output_high(PIN_C0);
delay_ms(1);
output_low(PIN_C0);
delay_ms(1);
}
}
|
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jul 24, 2012 11:11 am |
|
|
What's your compiler version ? |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Tue Jul 24, 2012 11:19 am |
|
|
PCH V4.129 |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jul 24, 2012 1:23 pm |
|
|
I don't have an 18F24K22, but I do have an 18F45K22 which is in the same
PIC family. I installed vs. 4.129 and I compiled your first program and
ran it on a PicDem2-Plus. It ran correctly. I measured pulses on Pin A7
which were low for 10ms, and high for 10ms.
I then compiled the program for the 18F24K22 and compared the two
.LST files. I don't see any differences between the two sets of code
that are of any importance.
I noticed you changed the i/o pin on your 2nd program. Are you sure
you were looking at Pin A7 with your oscilloscope when you tested your
first program ? |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Tue Jul 24, 2012 1:41 pm |
|
|
Hi PCM,
So you were able to get the first version to work? I did change the output from A7 to C0, but only for convenience. Neither output toggled with the first version of code. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jul 24, 2012 1:57 pm |
|
|
What programmer are you using, and what programmer software ? |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Tue Jul 24, 2012 2:05 pm |
|
|
I've always used MPLAB (currently V8.60) with an ICD2 programmer. I've worked with PIC18's many times in the past with no real problems. I have things working fairly well at the moment, but am still at a loss as to what was causing the problem with my first set of FUSEs. What is the best reference for the different fuses that are available for the various PICs? I've always used the Config Bits within MPLAB as a reference. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Jul 24, 2012 2:20 pm |
|
|
In your first program you are using the MCLR pin. But if you left off the
MCLR pull-up resistor, then your PIC might not run.
But then in your 2nd program, you added the NOMCLR fuse. This allows
the PIC to run properly without a pull-up resistor. That might explain
what you're seeing.
The larger issue is that you are changing multiple items per test and you
should only change one thing at a time, in order to isolate the problem. |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Tue Jul 24, 2012 2:24 pm |
|
|
I think the NOMCLR was the key since I don't have a pull-up on my reset line.
Thanks for all your help PCM! |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Wed Jul 25, 2012 9:26 am |
|
|
Can anyone explain why the output listing does show the assembly code for some subroutines and not others?
Code: |
.................... BYTE lcd_read_byte() {
.................... BYTE low,high;
....................
.................... set_tris_d(LCD_READ);
.................... lcd.rw = 1;
.................... delay_cycles(10);
.................... lcd.enable = 1;
.................... delay_cycles(10);
.................... high = lcd.data;
.................... lcd.enable = 0;
.................... delay_cycles(10);
.................... lcd.enable = 1;
.................... delay_us(1);
.................... low = lcd.data;
.................... lcd.enable = 0;
.................... set_tris_d(LCD_WRITE);
.................... return( (high<<4) | low);
.................... }
....................
|
|
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19509
|
|
Posted: Wed Jul 25, 2012 9:31 am |
|
|
#nolist
It's at the top of the processor include file - second line.
It tells the compiler to _not_ include assembly, for all the 'system' functions. Reason, it makes the listing much bigger, and generally it is _your_ code that you want to be debugging.
Remove it, and assembly will be included for everything.
Best Wishes |
|
|
MotoDan
Joined: 30 Dec 2011 Posts: 55
|
|
Posted: Wed Jul 25, 2012 9:47 am |
|
|
I understand the #nolist directive, however the LST file shows the disassembly some routines and not others. The routines are all in the same include file. I can force the output by adding a #list just before the routine and do in fact get the disassembly. Still unclear as to why some code gets disassembled and other code does not. |
|
|
|