Ping Spehro Pefhany question about PIC 18F14K22
in [Design]
|
From: Jan Panteltje on 4 Feb 2010 19:27 Ping Spehro Pefhany question about PIC 18F14K22 I have this PIC, and since you seem to be familiar with it, maybe you know the answer. When I program the PIC, I find that the code is only executed from about location decimal 60 decimal. That is everything before that location is ignored. The PIC jumps directly to org D'60'. Now there could be problems everywhere, but consider this code: org 0 goto start org 0x8 retfie org 0x18 retfie start: flip LED routine goto start Nothing happens. But this works: org 0 goto start org 0x8 retfie org 0x18 retfie org D'60' (any lower address no go). start: flip LED routine goto start Also I can write: reset: org 0 goto reset org D'60' start: flip LED routine goto start and that works! It does not hang in the reset loop! it skips over it! Lower then 60 for org does not work at all.... Only thing I can think of is that the PIC somehow enters debugging mode. I have read about a debugging flag. However in the related documents no debugging flag or related register is to be found. I have tried 2 PICs and both do exactly the same. I checked the generated code, and listed it from 2 different programmers, and also assembled it with 2 different assemblers one MPASM, the other gpasm, exactly the same result. The fact that the PIC skips the interrupt vector space makes it totally useless for me. Any ideas? All other code (no interrupts) executes normally after org D'60' or higher...
From: Paul E. Schoen on 5 Feb 2010 03:59 "Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message news:hkfolb$m1k$1(a)news.albasani.net... > Ping Spehro Pefhany question about PIC 18F14K22 > > I have this PIC, and since you seem to be familiar with it, > maybe you know the answer. > When I program the PIC, I find that the code is only executed from about > location decimal 60 decimal. > That is everything before that location is ignored. > The PIC jumps directly to org D'60'. > > Now there could be problems everywhere, but consider this code: > > org 0 > goto start > > org 0x8 > retfie > > org 0x18 > retfie > > start: > flip LED routine > goto start > > Nothing happens. > > > > But this works: > > org 0 > goto start > > org 0x8 > retfie > > org 0x18 > retfie > > org D'60' (any lower address no go). > start: > flip LED routine > goto start > > > Also I can write: > > reset: > org 0 > goto reset > org D'60' > start: > flip LED routine > goto start > > and that works! It does not hang in the reset loop! it skips over it! > Lower then 60 for org does not work at all.... > > Only thing I can think of is that the PIC somehow enters debugging mode. > I have read about a debugging flag. > However in the related documents no debugging flag or related register is > to be found. > I have tried 2 PICs and both do exactly the same. > > I checked the generated code, and listed it from 2 different programmers, > and also assembled it with 2 different assemblers one MPASM, the other > gpasm, > exactly the same result. > The fact that the PIC skips the interrupt vector space makes it totally > useless for me. > Any ideas? > > All other code (no interrupts) executes normally after org D'60' or > higher... I tried making a project with that PIC but I found MPLAB SIM is not available for it. However it is available for 18F14K50 and it assembled and ran OK, with the start loop at memory location 0x1A. I set the processor to 18F14K22 and reassembled. The disassembly listing still showed the loop at 0x1a. Same if I use Debug mode. I'm using MPLAB8.15a. Perhaps you should check your disassembly listing. And I assume you are only using the MPASM and not a C compiler which adds start-up code? I'm not familiar with that model PIC, but I checked the linker script files and found one that might cause such problems. I've never seen one quite like this. And the use of #FI for #ENDIF is a new one on me. Paul // File: 18f14k22_g.lkr // Generic linker script for the PIC18F14K22 processor #DEFINE _CODEEND _DEBUGCODESTART - 1 #DEFINE _CEND _CODEEND + _DEBUGCODELEN #DEFINE _DATAEND _DEBUGDATASTART - 1 #DEFINE _DEND _DATAEND + _DEBUGDATALEN LIBPATH . #IFDEF _CRUNTIME #IFDEF _EXTENDEDMODE FILES c018i_e.o FILES clib_e.lib FILES p18f14k22_e.lib #ELSE FILES c018i.o FILES clib.lib FILES p18f14k22.lib #FI #FI #IFDEF _DEBUGCODESTART CODEPAGE NAME=page START=0x0 END=_CODEEND CODEPAGE NAME=debug START=_DEBUGCODESTART END=_CEND PROTECTED #ELSE CODEPAGE NAME=page START=0x0 END=0x3FFF #FI CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED #IFDEF _EXTENDEDMODE DATABANK NAME=gpre START=0x0 END=0x5F #ELSE ACCESSBANK NAME=accessram START=0x0 END=0x5F #FI DATABANK NAME=gpr0 START=0x60 END=0xFF #IFDEF _DEBUGDATASTART DATABANK NAME=gpr1 START=0x100 END=_DATAEND DATABANK NAME=dbgspr START=_DEBUGDATASTART END=_DEND PROTECTED #ELSE //no debug DATABANK NAME=gpr1 START=0x100 END=0x1FF #FI DATABANK NAME=sfr15 START=0xF40 END=0xF5F PROTECTED ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED #IFDEF _CRUNTIME SECTION NAME=CONFIG ROM=config #IFDEF _DEBUGDATASTART STACK SIZE=0xA0 RAM=gpr0 #ELSE STACK SIZE=0x100 RAM=gpr1 #FI #FI
From: Spehro Pefhany on 5 Feb 2010 05:19 On Fri, 05 Feb 2010 00:27:13 GMT, the renowned Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >Ping Spehro Pefhany question about PIC 18F14K22 > >I have this PIC, and since you seem to be familiar with it, >maybe you know the answer. Hi, Jan:- Unfortunately, there are many more ways that things can go wrong than right. I've never seen this problem. But then I'm using vanilla MPLAB runing under XP, Win2K or Win7 64, plus ICD2, ICD3, PicKit2, PicStart, PicKit3 or RealICE. >When I program the PIC, I find that the code is only executed from about location decimal 60 decimal. >That is everything before that location is ignored. >The PIC jumps directly to org D'60'. Try using MPSIM and see what happens when you look at the program memory and when you step into the program from a simulated /MCLR reset. This works for me: ;------------------------------------------------------------------------------ ; RESET VECTOR ;------------------------------------------------------------------------------ RES_VECT ORG 0x0000 ; processor reset vector GOTO START ; go to beginning of program ;------------------------------------------------------------------------------ ; HIGH PRIORITY INTERRUPT VECTOR ;------------------------------------------------------------------------------ ISRH ORG 0x0008 ; Run the High Priority Interrupt Service Routine GOTO HIGH_ISR ;------------------------------------------------------------------------------ ; LOW PRIORITY INTERRUPT VECTOR ;------------------------------------------------------------------------------ ISRL ORG 0x0018 ; Run the High Priority Interrupt Service Routine GOTO LOW_ISR ;------------------------------------------------------------------------------ ; MAIN PROGRAM ;------------------------------------------------------------------------------ START ; dummy program that loops forever GOTO $ In this case, the value of START is 0x1C (28d), which is right after the 4-byte LOW_ISR vector (GOTO 0x36 in this case, located at 0x18-0x1B. >Only thing I can think of is that the PIC somehow enters debugging mode. >I have read about a debugging flag. >However in the related documents no debugging flag or related register is to be found. >I have tried 2 PICs and both do exactly the same. Well, when you use MPLAB the debug configuration bit is controlled "behind the scenes" by the selection of release vs. debug drop-down window (also there is a debug executive that is loaded into high program memory in debug mode). Microchip has taken to hiding this bit from unwashed data sheet users-- it's shown as "unimplemented" and "reads as zero". If you're using your own programming software you need to control it explicitly.. in this case it's bit 7 of CONFIG4L located at 300006h. Set it to '1' to disable background debug (and I also suggest disabling LVP). >I checked the generated code, and listed it from 2 different programmers, >and also assembled it with 2 different assemblers one MPASM, the other gpasm, >exactly the same result. >The fact that the PIC skips the interrupt vector space makes it totally useless for me. >Any ideas? > >All other code (no interrupts) executes normally after org D'60' or higher... Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff(a)interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Jan Panteltje on 5 Feb 2010 07:22 On a sunny day (Fri, 05 Feb 2010 05:19:57 -0500) it happened Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote in <42onm55ma60u6ib56i1prkuvrb6s714gc7(a)4ax.com>: >Well, when you use MPLAB the debug configuration bit is controlled >"behind the scenes" by the selection of release vs. debug drop-down >window (also there is a debug executive that is loaded into high >program memory in debug mode). Microchip has taken to hiding this bit >from unwashed data sheet users-- it's shown as "unimplemented" and >"reads as zero". If you're using your own programming software you >need to control it explicitly.. in this case it's bit 7 of CONFIG4L >located at 300006h. Set it to '1' to disable background debug (and I >also suggest disabling LVP). Wow! good data, now that is what I was looking for. I will try this, and of course also run your example, later tonight:-) Many thanks!
From: Jan Panteltje on 5 Feb 2010 07:23
On a sunny day (Fri, 5 Feb 2010 03:59:54 -0500) it happened "Paul E. Schoen" <paul(a)peschoen.com> wrote in <%6Ran.26740$p66.20530(a)newsfe09.iad>: > >"Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message >news:hkfolb$m1k$1(a)news.albasani.net... >> Ping Spehro Pefhany question about PIC 18F14K22 >> >> I have this PIC, and since you seem to be familiar with it, >> maybe you know the answer. >> When I program the PIC, I find that the code is only executed from about >> location decimal 60 decimal. >> That is everything before that location is ignored. >> The PIC jumps directly to org D'60'. >> >> Now there could be problems everywhere, but consider this code: >> >> org 0 >> goto start >> >> org 0x8 >> retfie >> >> org 0x18 >> retfie >> >> start: >> flip LED routine >> goto start >> >> Nothing happens. >> >> >> >> But this works: >> >> org 0 >> goto start >> >> org 0x8 >> retfie >> >> org 0x18 >> retfie >> >> org D'60' (any lower address no go). >> start: >> flip LED routine >> goto start >> >> >> Also I can write: >> >> reset: >> org 0 >> goto reset >> org D'60' >> start: >> flip LED routine >> goto start >> >> and that works! It does not hang in the reset loop! it skips over it! >> Lower then 60 for org does not work at all.... >> >> Only thing I can think of is that the PIC somehow enters debugging mode. >> I have read about a debugging flag. >> However in the related documents no debugging flag or related register is >> to be found. >> I have tried 2 PICs and both do exactly the same. >> >> I checked the generated code, and listed it from 2 different programmers, >> and also assembled it with 2 different assemblers one MPASM, the other >> gpasm, >> exactly the same result. >> The fact that the PIC skips the interrupt vector space makes it totally >> useless for me. >> Any ideas? >> >> All other code (no interrupts) executes normally after org D'60' or >> higher... > >I tried making a project with that PIC but I found MPLAB SIM is not >available for it. However it is available for 18F14K50 and it assembled and >ran OK, with the start loop at memory location 0x1A. I set the processor to >18F14K22 and reassembled. The disassembly listing still showed the loop at >0x1a. Same if I use Debug mode. I'm using MPLAB8.15a. > >Perhaps you should check your disassembly listing. And I assume you are >only using the MPASM and not a C compiler which adds start-up code? > >I'm not familiar with that model PIC, but I checked the linker script files >and found one that might cause such problems. I've never seen one quite >like this. And the use of #FI for #ENDIF is a new one on me. > >Paul > >// File: 18f14k22_g.lkr >// Generic linker script for the PIC18F14K22 processor > >#DEFINE _CODEEND _DEBUGCODESTART - 1 >#DEFINE _CEND _CODEEND + _DEBUGCODELEN >#DEFINE _DATAEND _DEBUGDATASTART - 1 >#DEFINE _DEND _DATAEND + _DEBUGDATALEN > >LIBPATH . > >#IFDEF _CRUNTIME > #IFDEF _EXTENDEDMODE > FILES c018i_e.o > FILES clib_e.lib > FILES p18f14k22_e.lib > > #ELSE > FILES c018i.o > FILES clib.lib > FILES p18f14k22.lib > #FI > >#FI > >#IFDEF _DEBUGCODESTART > CODEPAGE NAME=page START=0x0 END=_CODEEND > CODEPAGE NAME=debug START=_DEBUGCODESTART END=_CEND >PROTECTED >#ELSE > CODEPAGE NAME=page START=0x0 END=0x3FFF >#FI > >CODEPAGE NAME=idlocs START=0x200000 END=0x200007 >PROTECTED >CODEPAGE NAME=config START=0x300000 END=0x30000D >PROTECTED >CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF >PROTECTED >CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF >PROTECTED > >#IFDEF _EXTENDEDMODE > DATABANK NAME=gpre START=0x0 END=0x5F >#ELSE > ACCESSBANK NAME=accessram START=0x0 END=0x5F >#FI > >DATABANK NAME=gpr0 START=0x60 END=0xFF > >#IFDEF _DEBUGDATASTART > DATABANK NAME=gpr1 START=0x100 END=_DATAEND > DATABANK NAME=dbgspr START=_DEBUGDATASTART END=_DEND >PROTECTED >#ELSE //no debug > DATABANK NAME=gpr1 START=0x100 END=0x1FF >#FI > >DATABANK NAME=sfr15 START=0xF40 END=0xF5F >PROTECTED >ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF >PROTECTED > >#IFDEF _CRUNTIME > SECTION NAME=CONFIG ROM=config > #IFDEF _DEBUGDATASTART > STACK SIZE=0xA0 RAM=gpr0 > #ELSE > STACK SIZE=0x100 RAM=gpr1 > #FI >#FI Yes, those defines make sense, so far so good. thank you for the help :-) |