Prev: AMP01 Inst. amp replacement
Next: It's WAR! EEVblog ripoff
From: Jan Panteltje on 5 Feb 2010 09:26
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).


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.




From: Paul E. Schoen on 5 Feb 2010 17:10

"Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message
news:hkh9rj$624$1(a)news.albasani.net...
> 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).
>
>
> 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


From: Jan Panteltje on 5 Feb 2010 18:23
On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E. Schoen"
<paul(a)peschoen.com> wrote in <ZI0bn.151540$uH1.77806(a)newsfe25.iad>:

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

From: Paul E. Schoen on 8 Feb 2010 17:53

"Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message
news:hki99h$q5q$1(a)news.albasani.net...
> On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E.
> Schoen"
> <paul(a)peschoen.com> wrote in <ZI0bn.151540$uH1.77806(a)newsfe25.iad>:
>
>>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


From: Jon Kirwan on 8 Feb 2010 19:01
On Mon, 8 Feb 2010 17:53:35 -0500, "Paul E. Schoen"
<paul(a)peschoen.com> wrote:

>"Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message
>news:hki99h$q5q$1(a)news.albasani.net...
>> On a sunny day (Fri, 5 Feb 2010 17:10:12 -0500) it happened "Paul E.
>> Schoen"
>> <paul(a)peschoen.com> wrote in <ZI0bn.151540$uH1.77806(a)newsfe25.iad>:
>>
>>>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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: AMP01 Inst. amp replacement
Next: It's WAR! EEVblog ripoff