Author Topic: Help Again! My First PIC18F25K22 project should..but it doesn't blink a LED.  (Read 10347 times)

0 Members and 1 Guest are viewing this topic.

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
 |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   ==================================
« Last Edit: June 17, 2015, 08:50:02 pm by SuzyC »
 

Offline 22swg

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: gb
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
Check your tongue, your belly and your lust. Better to enjoy someone else’s madness.
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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;
« Last Edit: June 17, 2015, 08:28:33 pm by SuzyC »
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
This hex code runs on my 45k22 and flashes PortB,0 every 500ms. ( programmed with a Pk3)

Hopefully it will prove your programmer ..?
 

Offline 22swg

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: gb
Sorry being vague  >:D  , 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;
        }
        }
 
Check your tongue, your belly and your lust. Better to enjoy someone else’s madness.
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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?
« Last Edit: June 17, 2015, 08:16:32 pm by SuzyC »
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
Good show!, picandmix,  A thousand thanks!

BTW, is this like my code, using two priorities of interrupts?
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
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.
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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?
« Last Edit: June 17, 2015, 08:24:30 pm by SuzyC »
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
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
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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!
« Last Edit: June 17, 2015, 09:25:06 pm by SuzyC »
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
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
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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.
« Last Edit: June 17, 2015, 10:34:32 pm by SuzyC »
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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.
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
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
 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1433
  • Country: us
RTFDS

Section 10.1 - Note:

Section 10.3.1 - Note:

Section 10.4 - Note:
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
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.


 
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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!

 
« Last Edit: June 18, 2015, 02:24:56 am by SuzyC »
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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.
« Last Edit: June 18, 2015, 01:44:25 am by SuzyC »
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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.
« Last Edit: June 18, 2015, 02:21:24 am by SuzyC »
 

Offline SuzyCTopic starter

  • Frequent Contributor
  • **
  • Posts: 792
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.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
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. 

Quote
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.
Weird... works fine on my PC, which doesn't even have a parallel port!  Here's another one that might work better for you:-

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

 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
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
« Last Edit: June 18, 2015, 03:26:10 am by Bruce Abbott »
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
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 ??
« Last Edit: June 18, 2015, 10:59:49 am by picandmix »
 

Offline lewis

  • Frequent Contributor
  • **
  • Posts: 704
  • Country: gb
  • Nullius in verba
Pickit 2 is still available from Farnell, grab 'em while you can!

http://uk.farnell.com/microchip/dv164120/programmer-pickit2-for-pic/dp/9945350
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf