-
Help Again! My First PIC18F25K22 project should..but it doesn't blink a LED.
Posted by SuzyC on 17 Jun, 2015 12:00 -
|OI am a complete newbie to PIC18's but I am determined to learn all about it. Naturally, my first project would be a simple one to test basic operation, so I wrote the very short code below..but it doesn't quite work.
Does anyone see a problem with my code? I can't seem to find out what is wrong or missing!
I see that TMRx timers are quite complex to setup, perhaps I should have started out with TMR0..there are about a dozen settings to set and possibly set wrong with the 16-bit timers.
//----------------------------------------------
/* Test for PIC18F25K22 2015Jun16
NOTE: Compiled with Hi-Tech P18 PRO 9.80
My First PIC18F25K22 Program:
Should slowly blinks a LED on cbit3 ..it does, no IRQ, used for a blink, just For-Next loop timed.
A test to use low and high priority interrupts. cbit2 lights just for 50uSec when INT0 is triggered!
A test code using INT0 falling edge IRQ to light a LED
A test using the TMR1 overflow interrupt to blink LED on cbit2
I see with my scope about a .1 uSec glitch (lo-->hi-->lo)on cbit3 8uSec before cbit3 0-->1 but cbit3 then keeps LED lit for about a second correctly. This is strange, unexpected and evil, seems like something is clearing PORTC.
It should much faster blink a LED on cbit2 using low priority interrupt and TMR1, it doesn't!
It looks like TMR1 is not running? Why?
So far: cbit3 LED blinks almost perfectly
Alas, cbit2 LED does not respond to IRQ or TMR1 overflow and does not blink.
If I give INT0IF its own private I/O pin and its own LED to light in the high-priority interrupt, the INT0IF interrupt works perfectly.
*/
#include <htc.h>
#include <string.h>
#include <stdio.h>
#include <math.h>
#include <P18f25k22.h>
/*
#pragma config FOSC=0x88; //resets PRICLKEN bit5 of CONFIG1H
#pragma config PRICLKEN=0; //Primary Clock is disabled using Internal clk
#pragma config FOSC=0x5; //Coofig1H Default 0x2500 0001=0x25
#pragma config BORV=0; //Config2L Vdd level for BOREN to reset at
#pragma config BOREN=0; //BOREN Disabled
#pragma config PWRTEN=1; // 0002=0x1F
#pragma config WDTPS=0; //Ratio of Number of Clocks/WDTimerTic
#pragma config WDTEN=0; //WatchDog Enable Disabled 0003=0x3F ater erase
#pragma config MCLRE=1; //Pin 1 is *MCLR reset, not I/O pin
#pragma config PBADEN=0; //PORTB<0:5>are I/O pins not A2d inputs after reset
#pragma config T3CMX=1; //HFINTOSC is not delayed at startup
#pragma config CCP2MX=1; //CCP2 in/out is Mtplxd with RC2
#pragma config DEBUG=1; //Background Debugger is disabled
#pragma config XINST=0; //Extended instruction set DISABLED
#pragma config LVP=0; //LV programming disabled
#pragma config STVREN=1; //Reset on Stack Overflow or Underflow Enabled
Note: above just here for later use in my code instead of Magic Numbers
*/
//IES0 Allows internal/external clock swithover in OSCCON but is not used in program
//CONFIG1 System Clock
//Bit 7 6 5 4 <3:0>
// IESO FCMEM PRICLKEN PLLCFG OSC SELECT
// Int-Ext FailSafe no effect 0010 Xtal
// ClkSwEn Clock Mon HFINTOSC 1000 INTHFOSC
// 1=En 0=off 0=off x 0x1000
//OSCCON SCS=0 else no 64MHz PLL operation
//In this program 64MHz PLL is disabled, only 16MHz INTOSCBlock until things are looking better
__PROG_CONFIG(1,0x8800); //Internal Osc Block at 16MHz
__PROG_CONFIG(2,0x0); //BOREN and WDTEN both disabled
__PROG_CONFIG(3,0xBD00); //PBADEN disabled PORTB<5:0>are I/O, not A2d at reset
__PROG_CONFIG(4,0x85);
__PROG_CONFIG(5,0xC00F); //CONFIG4 to CONFIG7 set Read and Write protects, not used
__PROG_CONFIG(6,0xE00F); //All mem reads and writes are enabled, no protect
__PROG_CONFIG(7,0x400F); / /Default BulkErase settings for CONFIG4--CONFIG7
#pragma config IESO=1; //Needs to be=1 for SCS to work to set clk source
#pragma config PBADEN=0;
#pragma config WDTEN=0; //WatchDog Enable and BOREN Disabled, was 0x3F ater bulkerase
#define Off 0
#define OFF 0
#define off 0
#define On 1
#define ON 1
#define on 1
#define None 0
//Breaks the ports down into their bits
#define PB(port,bit) ((unsigned) & (port)*8 + (bit))
static bit abit0 @ PB(PORTA,0);
static bit abit1 @ PB(PORTA,1);
static bit abit2 @ PB(PORTA,2);
static bit abit3 @ PB(PORTA,3);
static bit abit4 @ PB(PORTA,4);
static bit abit5 @ PB(PORTA,5);
static bit abit6 @ PB(PORTA,6);
static bit abit7 @ PB(PORTA,7);
static bit bbit0 @ PB(PORTB,0);
static bit bbit1 @ PB(PORTB,1);
static bit bbit2 @ PB(PORTB,2);
static bit bbit3 @ PB(PORTB,3);
static bit bbit4 @ PB(PORTB,4);
static bit bbit5 @ PB(PORTB,5);
static bit bbit6 @ PB(PORTB,6);
static bit bbit7 @ PB(PORTB,7);
static bit cbit0 @ PB(PORTC,0);
static bit cbit1 @ PB(PORTC,1);
static bit cbit2 @ PB(PORTC,2);
static bit cbit3 @ PB(PORTC,3);
static bit cbit4 @ PB(PORTC,4);
static bit cbit5 @ PB(PORTC,5);
static bit cbit6 @ PB(PORTC,6);
static bit cbit7 @ PB(PORTC,7);
static double ttemp=0; //one and only var used for brute force timing in main()
void interrupt high_priority(void)
{
if (INT0IF)
{ INT0IF = 0;
cbit2=1;
}
if (TMR1IF)
{
TMR1ON = 0;
TMR1IF = 0;
TMR1H = 0x80;
TMR1L = 0x0;
TMR1ON = 1;
if(cbit2==0)
{ cbit2=1;
}
else cbit2=0;
}
}//End of High-Priority ISR
void interrupt low_priority lp(void)
{
if(INT0IF)
{ INT0IF=0;
cbit2=1;
}
if (TMR1IF)
{
TMR1ON = 0;
TMR1IF = 0;
TMR1H = 0x80;
TMR1L = 0x0;
TMR1ON = 1;
if(cbit2==0)
{ cbit2=1;
}
else cbit2=0;
}
}// end of Low priority interrupt
//____________________________ MAIN ___________________________________
void main(void)
{
OSCCON=0x70; //Selects Int Osc Block Clk as internal clock source
OSCTUNE=0x1F; //Highest Internal OSC Freq =16 MHz with OSCTUNE<0:5> sets freq abd PLLEN=bit6 sets turbo mode
//OSCTUNE<6:0>set freq 011111 =16MHz and turboed by PLL
PLLEN=1; //Enables PLL Fosc=Fosc*4 up to 64MHz with Internal 16MHz osc.
//PLLRDY //Status Bit 1=PLL ON
PORTB = 1; //Note: if a PORTA,B,C set to I/O, bit state of PORT is random
PORTA = 0; //unless set by these instructions
PORTC = 0;
INTEDG0=0; //interrupt on falling edge
TRISB = 0x1; //INTO pin set for digital input
TRISA = 0x0;
TRISC = 0x0; //all outputs on PORTC
T1GPOL=0; //TMR1 Gate Settings
T1G=0;
T1GTM=0; //Gate Toggle Mode turned off
T1GSPM=0; //Gate Single-Pulse mode disabled Not sure any TMR1 Gate Control stuff is needed, turned off
T1GCON=(T1GCON & 0x9); //T1GSS=Timer1 Gate pin
T1OSCEN=1; //Enable TMR1 Clocking
TMR1GE=1;
TMR1H = 0x0; //If this TMR1 is timing out, the scope must show it.
TMR1L = 0x0;
T1CON = 0b01001000; //Enables system clock as clock source for TMR1
//T1CKPS=00 1:1 prescaler of clock
TMR1IP = 0; //Low Priority interrupt enabled for TMR1.
TMR1ON = 1;
TMR1IF = 0;
TMR1IE = 1; //Enable TMR1 interrupt
INT0IE = 1; //Enable INT0 interrupt, it is always high priority
INT0IF = 0; //Not here reset?, probably needs to be reset in ISR
IPEN = 1; //High and Low interrupts enabled
PEIE=1; //turn on any possibly needed interrupt enables
PIE1=1;
PIE2=1;
GIEL=1;
GIEH=1; //Start the ball rolling (although is seems to shaped more like a brick)
//Progress, cbit3 LED always kinda blinks at about 1 second interval on/off
//Failure:
// ****** NOTE: cbit2 LED does not blink! ******** and even cbit2 doesn't stay lit with INT0 trigger
//----------------------------------------------------------------------
Start:
for(ttemp=0;ttemp<60000;ttemp++)//approx 1-second timed loop at 16MHz x 4
{ //cbit3 stays ON, as expected
cbit3=1; //There is a a 1K resistor connected to a LED to Vss
/ /cbit3 blinks, cbit2 should and doesn't, won't even stay lit for more than 50uSecs or so
if(TMR1IE==0) //NOTE: there is a 1K to +5 pullup on bbit0 INTIO0 bbit1
{ TMR1ON=0; // There is a LED connected to Vss with a 1k
cbit2=1; // resistor to cbit2 pin.
TMR1H = 0x0;
TMR1L = 0x0;
TMR1IF = 0; //Something's wrong: No cbit2 blink!
TMR1IE = 1;
TMR1ON = 1; //Start the timer to blink the cbit2 LED
}
INT0IE=0; //First it is TMR1's job to blink the LED
INT0IF=0;
}
for(ttemp=0;ttemp<60000;ttemp++) //Takes about a second at 16MHz x 4
{
if(TMR1IE==1) //If I ground bbit0 the cbit2 LED should light steady
{ TMR1IE=0; //N.O. Momentary switch connected from bbit0 to Vss
cbit2=0; //cbit2 stays off, something is wrong!
TMR1ON=0; //No blinking by TMR1, with only INT0 at work
TMR1IF=0; //TMR1 is turned off during this ttemp timed loop
}
cbit3=0; //cbit3 turns off and stays o as expected
TMR1IE = 0; //TMR1 is turned off, only bbit0 INT0 working
INT0IE = 1;
}
goto Start;
}
//======================== END of MAIN ==================================
-
This looks wrong ? {}{} ?Code: [Select]
if (TMR1IF)
{
TMR1ON = 0;
TMR1IF = 0;
TMR1H = 0x80;
TMR1L = 0x0;
TMR1ON = 1;
if(cbit2==0)
{ cbit2=1;
}
else cbit2=0;
}
}// end of Low priority interrupt -
Thanks Again, 22swg!
I can't see the problem you've see here..gimee a hint? Is it that I must add more code before attempting to modify TMR1H,L?
The code in question simply alternately toggles, blinks, turns on and off the LED on cbit2 with each TMR1 overflow interrupt. Interrupts are properly enabled, but the TMR1 perhaps never starts counting clocks.
If it is all possible for anyone to compile this masterpiece on their own IDE, and post the resulting intel .hex file, then I could check if this is some bug in my Hi-Tech P18 Pro compiler 9.80.
I saw that somewhere, someone on a coder forum said that 9.80 has a bug with interrupt priority code.
Interesting, I see in the .lst file created for this code that the high-priority interrupt was using interrupt level 2 and the low-priority interrupt was using interrupt level 1??
:040000002AEF00F0F3
:04000800BFEF04F052
:10001800D8CF01F0E8CF02F0E0CF03F09EA001D0E6
:1000280001D00DD0CD909E90D00ECF6ECE6ACD80EF
:1000380082B401D001D002D0828401D0829403C05E
The .hex file clearly shows code for the high-priority interrupt at address 0x0008 and the low-priority at location 0x0018.
It could also be my DIY programmer, but it does seem to be working quite perfect, it seems to verify the code burned into the MCU against the .hex file in all memory locations, so, I a flummoxed!
The beginning of the .lst file for the lp low-priority interrupt:
73 ;;Total ram usage: 3 bytes
74 ;; Hardware stack levels used: 1
75 ;; Hardware stack levels required when called: 1
76 ;; This function calls:
77 ;; Nothing
78 ;; This function is called by:
79 ;; Interrupt level 1
80 ;; This function uses a non-reentrant model
81 ;;
82
83 psect intcodelo
84 000018 __pintcodelo:
85 opt stack 0
86 000018 _lp:
87 opt stack 26
88 000018 CFD8 F001 movff status,??_lp
89 00001C CFE8 F002 movff wreg,??_lp+1
90 000020 CFE0 F003 movff bsr,??_lp+2
91 000024
92 ;Test.c: 126: if(INT0IF)
93 000024 A2F2 btfss intcon,1,c ;volatile
94 000026 D001 goto i1u4_21
95 000028 D001 goto i1u4_20
96 00002A i1u4_21:
97 00002A D002 goto i1l110
98 00002C i1u4_20:
99 00002C
100 ;Test.c: 127: { INT0IF=0;
101 00002C 92F2 bcf intcon,1,c ;volatile
102
103 ;Test.c: 128: cbit2=1;
104 00002E 8482 bsf 3970,2,c
105 000030 i1l110:
106
107 ;Test.c: 129: }
108 ;Test.c: 131: if (TMR1IF)
109 000030 A09E btfss 3998,0,c ;volatile
110 000032 D001 goto i1u5_21
111 000034 D001 goto i1u5_20
112 000036 i1u5_21:
113 000036 D00D goto i1l114
114 000038 i1u5_20:
115 000038
116 ;Test.c: 132: {
117 ;Test.c: 133: TMR1ON = 0;
118 000038 90CD bcf 4045,0,c ;volatile
119
120 ;Test.c: 134: TMR1IF = 0;
121 00003A 909E bcf 3998,0,c ;volatile
122 00003C
123 ;Test.c: 135: TMR1H = 0x80;
124 00003C 0E80 movlw 128
125 00003E 6ECF movwf 4047,c ;volatile
126 000040
127 ;Test.c: 136: TMR1L = 0x0;
128 000040 6ACE clrf 4046,c ;volatile
129 000042
130 ;Test.c: 137: TMR1ON = 1;
131 000042 80CD bsf 4045,0,c ;volatile
132 000044
133 ;Test.c: 138: if(cbit2==0)
134 000044 B482 btfsc 3970,2,c
135 000046 D001 goto i1u6_21
136 000048 D001 goto i1u6_20
137 00004A i1u6_21:
138 00004A D002 goto i1l112
139 00004C i1u6_20:
140 00004C
141 ;Test.c: 139: { cbit2=1;
142 00004C 8482 bsf 3970,2,c
143
144 ;Test.c: 140: }
145 00004E D001 goto i1l114
146 000050 i1l112:
147
148 ;Test.c: 141: else cbit2=0;
-
This hex code runs on my 45k22 and flashes PortB,0 every 500ms. ( programmed with a Pk3)
Hopefully it will prove your programmer ..?
-
Sorry being vague
, but should there not be an extra { or is this ok in hitec ... but there again picandmix got it to run ? Code: [Select]{
TMR1ON = 0;
TMR1IF = 0;
TMR1H = 0x80;
TMR1L = 0x0;
TMR1ON = 1;
if(cbit2==0)
{ cbit2=1;
}else{
cbit2=0;
}
} -
Thanks 22swg, but the program compiles and Hi-tech never misses a miss-matched phrase of my poetry, look again to see there exits one } for every { .
But brother, can you spare me a.hex file? -
Good show!, picandmix, A thousand thanks!
BTW, is this like my code, using two priorities of interrupts? -
No, its written in Pic Assembly Code.
Its from an old project, just edited it to flash a led using a software delay so you had the proven 45K22 .hex code you wanted.
I have used a 32k crystal and Tmr1 with the high priority interrupt to run a RTC on a 18F4520 for years; works well. -
OMG
I just burned your code into my breadboarded MCU and got quite a different story than was promised.
I see all ports pins are at Vss except for cbit2 and cbit3 which have identical, but odd pulse trains.
The waveform repeats every 4-seconds, it is active for 2 seconds an at Vss for two seconds.
When active the waveform consists of 2-mSec (lo) spaced 8-uSec(hi) square pulses for the entire two seconds.
This waveform looks like a comb, and I m pulling out my hair!
To repeat, there is no activity on PORTA nor PORTB, PORTB.0 (bbit0) has a pull-up and remains at +Vdd.
I just don't get how my programmer can put these same bytes in the locations specified in the hex file, can repeatedly verify that they are indeed there and so I see that I write right addresses, yet I get these results on PORTC instead of PORTB, yet I can see all the CONFIG bytes match perfectly, and the 20-MHz Xtal attached to the proper pins is not active, Pin1 is *MCLR reset and resets properly, and it is obviously using the internal clock, and producing a kinda blink with a period of 4-seconds, 50% duty cycle comb waveform.
Could you or any other good samaritan run my hexfile on your PICKIT3 to see whatcha get?
-
My code was using the internal osc and all the config parameters are within the .hex file.
Port A and E defined as input, all else as outputs.
Have just loaded your code and its flashing away on RC3 at 1 sec.
The first shot is my code, the second your code , config data at the top right ; programmed this time via the Pk2, but that can only be done using the stand alone program PK2 V2.61
-
Thanks a gadzillion, pickandmix, but cbit3 was the only pin timed by a for-next loop and was working correctly, (almost, there is a mysterious 8-uSec glitch I've mentioned above.)
Please note that cbit2 is the problem pin. The cbit2 pin shows the actions of all the interrupts and TMR1 count operation.
You hexed help is just what a damsel coder in distress needed.
I can see that my super-duper suzyburn pickit clone might be somehow clowning me ...or is it?
I will use the memory read function of my device to see what is the difference between what is read and what is wrote. It seems to be putting the bytes in the right places, but if I could get a mem dump of your correctly programmed chip, then I could compare the actual bytes read from your MCU to what I read from my MCU.
The trouble might be in the first code, the interrupt routines, but you show your screenshot of code.. (is this a dump of the MCU..or is it the hex code file)? But then the screenshot of my code(again, is this the hex file or MCU dump??) display starts at location 0x0030.
Very hard to compare the two, but hanks again for taking the effort to help! -
I do not have every pin of the 45k22 on a led, have just checked all other pins with a dmm and no other pins seem active, some high, some low .
Think I mentioned early on about your initial diy programmer problems that a breadboard can give strange problems, partic if using and external crystal and caps, their fine leads can 'loose' the signals.
Also the length of wire between the programmers output and the breadboard should be as short as possible, less that 100mm ideal.
Would not start moving code around after its been complied, you will just get errors.
My code example has these config settings and Oscon is set to 8mhz
( ignore the eeprom data in my old code, forget to remove it )
; CONFIG directives for 18F45K22
;
; All Code and Memory Protections are OFF, see .INC file for details if needed.
;Setup CONFIG11H
CONFIG FOSC = INTIO7, PLLCFG = OFF, PRICLKEN = OFF, FCMEN = OFF, IESO = OFF
;Setup CONFIG2L
CONFIG PWRTEN = OFF, BOREN = OFF, BORV = 190
;Setup CONFIG2H
CONFIG WDTEN = OFF, WDTPS = 1
;Setup CONFIG3H
CONFIG MCLRE = INTMCLR, CCP2MX = PORTB3, CCP3MX = PORTE0, HFOFST = OFF, T3CMX = PORTB5, P2BMX = PORTD2
;Setup CONFIG4L
CONFIG STVREN = OFF, LVP = OFF, XINST = OFF
;Setup CONFIG5L
CONFIG CP0 = OFF, CP1 = OFF, CP2=OFF, CP3=OFF
;Setup CONFIG5H
CONFIG CPB = OFF, CPD = OFF
;Setup CONFIG6L
CONFIG WRT0 = OFF, WRT1 = OFF, WRT2 = OFF, WRT3 = OFF
;Setup CONFIG6H
CONFIG WRTB = OFF, WRTC = OFF, WRTD = OFF
;Setup CONFIG7L
CONFIG EBTR0 = OFF, EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF
;Setup CONFIG7H
CONFIG EBTRB = OFF -
Thanks again picandmix, but I am quite sure the trouble is not a HW problem.
There are no Xtals, used, no external MCU, the interface is directly to just four PC Parallel Port pins via some open-collector LSTTL gates. I have scoped the Pdat and PClk data carefully and both waveforms are very clean and required delays required in the programming timing diagrams in every case exceed the Min. specs by a large margin.
My very first attempt to verify correct operation didn't use any interrupts, but still, there were anomalies in the clock waveforms.
When I use exactly the same hardware, but of course, different code, to program 16F88x chips there is never a problem.
Methinks there is something softwarish screwy. -
Do Pickit2/3 allow to dump the burned contents of a MCU programmed unprotected to a file?
Maybe that isI would like to see to get to the core of the problem.
But how can my programmer read all the bytes at their proper location and consistently and match them to their correct addresses in the .hex file and yet the MCU result is completely psycho. -
Cannot answer all your questions but as you can see from those PK2 screen shots you can see the program code to be burnt in the Program Memory panel.
Don't know what software you are using to burn your code, but most have a similar buffer/ panel to see and even edit the hex code.
Also once burnt you should have a verify sequence which should confirm the buffer and chip hold the same code and importantly the same config paramenters.
As in that screenshot you can see where I have actually read the chip code back into the buffer before reprogramming it, so you can do a visual inspection of whats been burnt.
If my basic code did not run properly then it sounds like you are still getting problems with yo programmer routine /hw ?? - though must confess I did not follow all of your previous long thread on that ...
Just one point on your C code, (which I do not know/ use), you have this Config which sets port B to digital, but I do not see any use of ANSEL to set all the other ports to Digital, the power on default is analogue Input.
In Assembly you have to manual tell it / use ANSELs to make them digital, don't know if C does it automatically ??
#pragma config PBADEN=0; //PORTB<0:5>are I/O pins not A2d inputs after reset
-
RTFDS
Section 10.1 - Note:
Section 10.3.1 - Note:
Section 10.4 - Note: -
how can my programmer read all the bytes at their proper location and consistently and match them to their correct addresses in the .hex file and yet the MCU result is completely psycho.
It may be storing bytes in the wrong locations. If read out of the same wrong locations it will appear to be correct, but the code will not work properly.
The obvious way to find where your programmer is actually writing the data is to read it back with another programmer that is known to work correctly. But of course to do that you need another programmer, which I am guessing you don't have (otherwise why bother making your own?). However you do have a PC with a parallel port, so you could try building a programmer such as the Oshonsoft Parallel Port PIC-PIC18 Programmer (http://www.oshonsoft.com/picprogparallel.html) which supports the 18F26K22 and so should be able to read the 18F25K22.
-
Many thanks Skimask, this is an epiphany. Thank you very much for pointing this out to me.
I can see how pin function prioritization could explain the glitches because another function is also trying to output to the same pin.
I know I am a newbie to this chip, it just seemed so non-intuitive that an I/O pin would allow another function to be active on that same pin, since I always assumed that the alternate function of a bin had to be software enabled to have that effect.
In the case of the P18F25K22, it seems that other functions than simple I/O can be the default function. Silly me, I thought they just needed be just TRIS'd to become outputs.
That being the case, I still will certainly study more carefully how to initialize the MCU pins I am using and RTFM!
That's a big 10-4, Skimask!
-
thanks, Bruce Abbot, but this sounds more like a science-fiction story than reality. Unless an obfuscation function was enabled by code read/write protect bits, this scenario is just not possible without it being front page news in the specsheet for programming this device, for which I have RTFM.
Perhaps Skimask has better defined the problem, the code might be correctly programmed into the MCU but the code is defective because the code's target pins are configured wrong.
Garbage In--->Garbage Out!
Fascinating, picandmix programmed one of his own with my .hex file and then tested the only pin that was working correctly(at first glance) and then reports that my program works. -
Thanks again Bruce Abbot,
I downloaded the Parallel Port programmer from the link you provided and installed the .exe program.
The program crashed and closed while I was only attempting to select a device to be programmed.
At least it is a free program. Program was written by Vladimir Soso.
I would say this software is validly just so-so. -
Two questions remain:
1) Does Hi-Tech P18 PRO have a bug that miscodes interrupt priority?
Although I could get the program to work in its own crippled way, it never responded to a low-priority interrupt, but did respond in compatibility mode single ISR mode.
2)Is my DIY programmer really defective..A sure way to prove this would for someone to download the .hex file I've posted and tell me that they get different results or for someone else to provide a test or another program's .hex file that is known to work properly even just blinking a LED or two and responding to low and high priority interrupts with the 18F25K22.
So far, I am still not certain where the problem lies. -
Perhaps Skimask has better defined the problem, the code might be correctly programmed into the MCU but the code is defective because the code's target pins are configured wrong.
Two identical chips programmed with the same hex file should work the same. picandmix's hex works in his chip, but not yours. Your code also works in his chip, but not in yours. The only difference is the programmer, so unless you have a hardware fault (broken chip, bad wiring etc.) the obvious conclusion is that your chip is not being programmed correctly.QuoteI downloaded the Parallel Port programmer from the link you provided and installed the .exe program.
Weird... works fine on my PC, which doesn't even have a parallel port! Here's another one that might work better for you:-
The program crashed and closed while I was only attempting to select a device to be programmed.
meProg 4.52.0 Beta (use with circuit below) http://melabs.com/support/progsoft.htm
pic³prog parallel port programmer http://urriellu.net/en/projects-electronics/pic3prog-pic-programmer-parallel-port.html
-
Can you explain this anomaly? Number in hex file doesn't match source code.
Your source code:-
void interrupt low_priority lp(void)
{
if(INT0IF)
{ INT0IF=0;
cbit2=1;
}
if (TMR1IF)
{
TMR1ON = 0;
TMR1IF = 0;
TMR1H = 0x80;
TMR1L = 0x0;
TMR1ON = 1;
if(cbit2==0)
{ cbit2=1;
}
else cbit2=0;
}
}// end of Low priority interrupt
Your hex file disassembled:-
0030 0ED0 MOVLW 0xd0
0032 6ECF MOVWF 0xfcf ; TMR1H
-
Probably not what you want to hear, but like many I also started off with the diy pic programmers but soon found they were very limiting and problematic.
While I admire your tenacity in trying to build you own programmer and software, I found that with then such a limited knowledge it would be pointless me then trying to do the same so I opted to purchase a then quiet expensive PK2.
Since then I never looked back, the Pk2 gave 100% reliable programming of most hobbyist chips, plus added extas like programmer to go, usart and logic analyzer tools.
It then lets you concentrate on leaning how to complete and test your projects without the worry of 'is it being programmed right ? '
The plans Bill showed for the Pk2 basic clone will, with a updated Pk2 .dat file, program many 18F J and K series chips via its V2.61 free program , as you can see from my screenshots.
The catch is that with these later chips it that they cannot be programmed direct from Mplab IDE and cannot be run from Mplabs IDE Debugger, for that you have to use a Pk3 ( which is not a practical diy build)
I was about to say I would post you over a programmed 2550 chip so you could build your own Pk2 clone, but it hardly seems worth it when you can get a complete Pk2 for less than $10
EDIT
Footnote - even if you manage to sort out the software for the 18F45K22 programming, are you going to go through the same exercise for each new family of Pic you advance on to , eg 18F J , Pic24, Pic32 etc etc ??
-
Pickit 2 is still available from Farnell, grab 'em while you can!
http://uk.farnell.com/microchip/dv164120/programmer-pickit2-for-pic/dp/9945350