Re: Ping Spehro Pefhany question about PIC 18F14K22

On Fri, 05 Feb 2010 00:27:13 GMT, the renowned Jan Panteltje
<(E-Mail Removed)> 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"
(E-Mail Removed) Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

"Jan Panteltje" <(E-Mail Removed)> wrote in message
news:hkh9rj$624$(E-Mail Removed)...
> On a sunny day (Fri, 05 Feb 2010 05:19:57 -0500) it happened Spehro
> Pefhany
> <(E-Mail Removed)> wrote in
> <(E-Mail Removed)>:
>
>>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 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.
>
> 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.

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

"Jan Panteltje" <(E-Mail Removed)> wrote in message
news:hki99h$q5q$(E-Mail Removed)...
> On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E.
> Schoen"
> <(E-Mail Removed)> wrote in <ZI0bn.151540$(E-Mail Removed)>:
>
>>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
>
> 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...

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

On Mon, 8 Feb 2010 17:53:35 -0500, "Paul E. Schoen"
<(E-Mail Removed)> wrote:

>"Jan Panteltje" <(E-Mail Removed)> wrote in message
>news:hki99h$q5q$(E-Mail Removed)...
>> On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E.
>> Schoen"
>> <(E-Mail Removed)> wrote in <ZI0bn.151540$(E-Mail Removed)>:
>>
>>>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
>>
>> 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...
>
>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.

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.

>Probably ADD so they only remembered the last paragraph.

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.

>I left a comment and maybe I will hear a
>response, but they marked the issue as "resolved". But not closed...

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

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

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

Jon