Ping Spehro Pefhany question about PIC 18F14K22

Fri Feb 05, 2010 2:27 am   

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...

Fri Feb 05, 2010 10:59 am   

"Jan Panteltje" <pNaonStpealmtje_at_yahoo.com> wrote in message
news:hkfolb$m1k$1_at_news.albasani.net...

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

Fri Feb 05, 2010 12:19 pm   

On Fri, 05 Feb 2010 00:27:13 GMT, the renowned Jan Panteltje
<pNaonStpealmtje_at_yahoo.com> wrote:


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.


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.


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).



Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff_at_interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

Fri Feb 05, 2010 2:22 pm   

On a sunny day (Fri, 05 Feb 2010 05:19:57 -0500) it happened Spehro Pefhany
<speffSNIP_at_interlogDOTyou.knowwhat> wrote in
<42onm55ma60u6ib56i1prkuvrb6s714gc7_at_4ax.com>:



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!

Fri Feb 05, 2010 2:23 pm   

On a sunny day (Fri, 5 Feb 2010 03:59:54 -0500) it happened "Paul E. Schoen"
<paul_at_peschoen.com> wrote in <%6Ran.26740$p66.20530_at_newsfe09.iad>:


Yes, those defines make sense, so far so good.
thank you for the help

Fri Feb 05, 2010 4:26 pm   

On a sunny day (Fri, 05 Feb 2010 05:19:57 -0500) it happened Spehro Pefhany
<speffSNIP_at_interlogDOTyou.knowwhat> wrote in
<42onm55ma60u6ib56i1prkuvrb6s714gc7_at_4ax.com>:



I wrote:
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!


OK, I have tried it and it works now 100% OK, with rather complicated code too.

A few suggestions to Microchip:

1) That debug bit is by default enabled it seems, as the assembler (gpasm) generates a 0 for that bit.
Debug is not a normal processor mode, and not even a wanted mode by many, so by default it should just behave normally.
2) As you address a rather large market, and millions are using other operating systems
and other programmers, the debug bit MUST be documented.
Otherwise you end up with a lot of frustrated programmers, who then turn away from the PIC for 'something that works'.

I personally think the debug bit is not a feature but a bug!
A car that keeps the doors closed when you want to get in, is a just not a smart idea.
If this is an attempt to sell more of your own programmers, it is a very very bad idea.


So for the public interest, here for the PIC 18F14K22 the real config space:

This example I used the internal oscillator, and disabled the MCLRE reset.

CONFIG FOSC = IRCCLKOUT ; Internal RC oscillator, CLKOUT function on OSC2
CONFIG MCLRE = OFF ; RA3 input pin enabled CONFIG MCLR disabled

From gpasm assembler HEX file:
:02 0000 04 0030 CA Extended Intel hex record, upper bytes new base address 0x3000
:0E 0000 00 FF 29 1F 1F FF 08 05 FF 03 C0 03 E0 03 40 98 length, lower bytes address, data for config registers, checksum

The data part: FF 29 1F 1F FF 08 05 FF 03 C0 03 E0 03 40
---------------------------------^^
BUT bit 7 CONFIG4L 300006h must be 1 to disable debug.



This should go in the 18F1XK22_FLASH programming specs document 41357B.pdf, page 256:

TABLE 22-1: CONFIGURATION BITS AND DEVICE IDs
Default/
File Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Unprogrammed
Value
300000h ff
300001h CONFIG1H IESO FCMEN PCLKEN PLL_EN FOSC3 FOSC2 FOSC1 FOSC0 0010 0111 29 fosc intern to pin 3
300002h CONFIG2L -- -- -- BORV1 BORV0 BOREN1 BOREN0 PWRTEN ---1 1111 1f
300003h CONFIG2H -- -- -- WDTPS3 WDTPS2 WDTPS1 WDTPS0 WDTEN ---1 1111 1f
300004h ff
300005h CONFIG3H MCLRE -- -- -- HFOFST -- -- -- 1--- 1--- 08 !MCLR
300006h CONFIG4L !DEBUG XINST -- -- BBSIZ LVP -- STVREN -0-- 01-1 05 ***** bit 7 CONFIG4L 300006h must be 1 to disable debug. ****
300007h ff
300008h CONFIG5L -- -- -- -- -- -- CP1 CP0 ---- --11 03
300009h CONFIG5H CPD CPB -- -- -- -- -- -- 11-- ---- c0
30000Ah CONFIG6L -- -- -- -- -- -- WRT1 WRT0 ---- --11 03
30000Bh CONFIG6H WRTD WRTB WRTC -- -- -- -- -- 111- ---- e0
30000Ch CONFIG7L -- -- -- -- -- -- EBTR1 EBTR0 ---- --11 03
30000Dh CONFIG7H -- EBTRB -- -- -- -- -- -- -1-- ---- 40

Legend: x = unknown, u = unchanged, ­ = unimplemented, q = value depends on condition.


May google find this for all who also try to write a PIC 18F14K22 programmer.
No idea if it is the same for other PIC 18F types.

A final remark:
I think low voltage programming is a bad idea, as it sacrifices an other pin on a 20 pin package.
Always short of I/O, and MCLRE is already restricted to input only, and there are restrictions on program data and program clock inputs too.
Also I do not see how you can guarantee that the application circuit will never accidently enter a programming sequence.

Sat Feb 06, 2010 12:10 am   

"Jan Panteltje" <pNaonStpealmtje_at_yahoo.com> wrote in message
news:hkh9rj$624$1_at_news.albasani.net...

FYI, I submitted the following on the Microchip Forum and I also submitted
a defect ticket:

There was a recent discussion in the newsgroup sci.electronics.design about
a problem with programming the PIC18F14k22, and it was determined that the
DEBUG bit in the CONFIG4L register had to be set to 1 to disable the
debugger. In the documentation for this and the PIC18F14k50, this bit is
reported as unused and read as a zero. However, this IS the DEBUG bit and
it must be specifically set to 1 in order to program and use the part
properly. It may be that MPLAB and the usual programmer hardware takes care
of this automatically, but it is a problem for third party and homebrew
programmers.

It is especially strange that the bit is preset to zero, while in other
parts, such as the PIC18F2420, it is preset to 1, and the documentation
clearly specifies it as the DEBUG bit. The literature for the PIC18F14kxx
refer to the DEBUG bit in the section on the debugger, but the
identification of the bit in the CONFIG4L register has been removed and
replaced with the incorrect information.

I'm not using these parts, and I use Microchip ICD2 and MPLAB, so it might
not be a problem for me if I do.

One other oddity is that the MPLAB 8.15a SIM does not support the k22 part
but it does work for the k50 part. Maybe it's been added to a newer
release. I think these are fairly new parts.

Paul

Sat Feb 06, 2010 1:23 am   

On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E. Schoen"
<paul_at_peschoen.com> wrote in <ZI0bn.151540$uH1.77806_at_newsfe25.iad>:


Thank you, good they know about it.
I am not sure what the bit value is by default, but I do see that the assembler
writes a zero there.
So I added a line of code to my programmer that overrules any input, and sets
that bit to one (or leaves it at one).
Chip works great now, have the internal clock at 16 MHz and 4 x PLL enabled for 64 MHz,
seems to work.
Just playing around with it.
Wrote some macros to port the old 16F690 instructions...

Tue Feb 09, 2010 12:53 am   

"Jan Panteltje" <pNaonStpealmtje_at_yahoo.com> wrote in message
news:hki99h$q5q$1_at_news.albasani.net...

I got a response from Microchip and they glossed over my questions about
the erroneous documentation and the possible wrong default bit setting in
the silicon, and instead told me that the new version of MPLAB does support
this device. Shame on me for confusing them. Probably ADD so they only
remembered the last paragraph. I left a comment and maybe I will hear a
response, but they marked the issue as "resolved". But not closed...

There is another thread about this device and apparently there is a problem
in the MSSP module:
http://www.microchip.com/forums/tm.aspx?m=474280

Glad you got it working.

Paul

Tue Feb 09, 2010 2:01 am   

On Mon, 8 Feb 2010 17:53:35 -0500, "Paul E. Schoen"
<paul_at_peschoen.com> wrote:


Don't stop there. I've taken the time to carefully box
things into a corner with them where there was no possible
escape except either a "No, we won't answer that." or else a
"Yes, and here is where to go." It was somewhat painful,
because they were seemingly getting adept at evading things.
But the way to do it was to not write a reply to them that
addressed _anything else_ but the point I wanted to have an
answer on. If you include _any_ other topic or sentence in
your response, they will latch onto that part and "appear" to
somehow miss the main point.

Stay on target. Nail them.


What happened may be that you left them a 'last paragraph' to
focus on, while ignoring the rest. Try another shot, only
this time make sure there is only ONE thing to respond to.
Don't even include "the weather here is nice" because that
may be what they latch onto, if you do.


Hopefully, a __narrowly__ worded response. Thanks for
pressing. I'd like to hear the results, too!


I'm sure he is, too. Spehro may have saved him a lot of
wrangling.

Jon

Tue Feb 09, 2010 3:13 pm   

On a sunny day (Mon, 8 Feb 2010 17:53:35 -0500) it happened "Paul E. Schoen"
<paul_at_peschoen.com> wrote in <BD0cn.57430$s%.25209_at_newsfe18.iad>:


No, not your fault, Microchip should release complete specs.
That will make life easier for programmers like those who write gpasm,
as then the debug bit can just be a CONFIG option for this chip,
so it should be in P18F14K22.INC.
It should *not* be something that the programmer software does.

Anyways, I do not use debug, never do, last time was in the eighties with CP/M.
Usually when people grab to debug it means they have no oversight of what they are doing.
How do you think I concluded it was the debug feature that was the problem?
Using debug? Come on guys, learn to program!
And that means analysis, most cases what is the problem has already showing all symptoms
clearly in front of your nose.
Two things you need to have: 1) A clear mind, and 2) know about successive approximation.
So that was a little bit of philosophy :-)



My experience with 'help desks' of any company is very very bad.
Latest was with Vodafone, I asked them where the transmitter mast for my GSM phone was,
(so I could erect an external antenna to get better reception for GPRGS modem at home),
and they simply ignored the question... and gave some stupid answer about
that if enough complaints came in they would move the beam a bit (perhaps).
Now Vodafone is not doing very well, can you imagine why, I will be out of there as soon as anything
better manifests.



I have ported a rather complicated program from 16F690 to 18F14K22, and needed quite a few modifications.
as register have beend added, flags have been moved to other registers,
the instruction set has changed, other things have changed, but i got it all working
including WDT, BOR, and interrupts, but have not tried MSSP SPI yet, as I do not need it.
But it likely is some user config problem.
Reading datasheets, at times I go over it again, and try out all those cool hardware peripherals.
It really is a very nice chip.



I may publish that asm that later, on the io_pic page.
The asm file is >3900 lines, but I included a lot of docs into it.
Memory about half full
Program 7500 bytes at address 0x000000
ID 0 bytes at address 0x200000
Config 14 bytes at address 0x300000
EEPROM 0 bytes at address 0xf00000
I think the programmer software is now pretty much finished, only thing to add would be more 18F PIC types.
And that at version 0.2!
http://panteltje.com/panteltje/pic/jppp18/index.html

Tue Feb 09, 2010 3:18 pm   

On a sunny day (Mon, 08 Feb 2010 16:01:01 -0800) it happened Jon Kirwan
<jonk_at_infinitefactors.org> wrote in
<c491n5l6kb7po60nkepodf4mcgv7iu9ru8_at_4ax.com>:


Of course he did not save me time, he recommended that chip to me
Else I would be doing something else
Thank you Spehro !
hehe

LOL

Well, at least the world now has a better programmer:
http://panteltje.com/panteltje/pic/jppp18/index.html