Searching \ for '[PIC]: ICD2 programming failure: ICD0083: Target' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'ICD2 programming failure: ICD0083: Target'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: ICD2 programming failure: ICD0083: Target'
2005\12\01@221112 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not in debug mode, unable to perform operation

What is this?

Yes, I read about it in the 'help', and it was typical
Gates - intolerably flashy code bloat - and zero help.

I have used my new USB ICD2 with my new PIC dem HPC
Explorer PIC18F8722 for several weeks with excellent
results.

Now, after "build all", "select debugger", "program",
the error manifests.  It always worked before.

Good power to the PIC dem, USB power to the ICD2, just
the same as always.

To prove something, I loaded the Microchip hexadecimal
file for the C source demonstration program that came
with the PIC dem, and that all worked just fine.

In my perfectly(!) working configuration include file,
I have always explicitly turned off debug - I want to
know where I am! - and now I have turned debug on,
then back off, with no help.


It worked before.  Any ideas?


Thanks!

Grinder


               
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

2005\12\01@221757 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not in debug mode, unable to perform operation

What is this?

Yes, I read about it in the 'help', and it was typical
Gates - intolerably flashy code bloat - and zero help.

I have used my new USB ICD2 with my new PIC dem HPC
Explorer PIC18F8722 for several weeks with excellent
results.

Now, after "build all", "select debugger", "program",
the error manifests.  It always worked before.

Good power to the PIC dem, USB power to the ICD2, just
the same as always.

To prove something, I loaded the Microchip hexadecimal
file for the C source demonstration program that came
with the PIC dem, and that all worked just fine.

In my perfectly(!) working configuration include file,
I have always explicitly turned off debug - I want to
know where I am! - and now I have turned debug on,
then back off, with no help.


It worked before.  Any ideas?


Thanks!

Grinder


               
__________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

2005\12\02@015542 by Chen Xiao Fan

face
flavicon
face
>subject:  [PIC]:  ICD2 programming failure:  ICD0083:
>Target not in debug mode, unable to perform operation
>
>What is this?

This might help:
http://ww1.microchip.com/downloads/en/DeviceDoc/ICD2_Advisory_51566b.pdf

I suspect the crosstalk is the problem for you. But it can be
other things as well.

Have you updated your MPLAB? V7.22 is said to have some problems
with ICD2 for certain MCUs like 18F USB parts.

Regards,
Xiaofan

2005\12\02@154355 by Barry Gershenfeld

face picon face

>Target not in debug mode, unable to perform operation
>What is this?
>Yes, I read about it in the 'help', and it was typical Gates - intolerably
>flashy code bloat - and zero help.

When you select debugger and program the chip, it downloads a monitor along
with your program.  The
error message means that either the debug bit isn't enabled, or that it's
unable to talk to that monitor
code.

After awhile I formed a mental list of things to try when the ICD won't
play.  I say "mental" because
mine is inexact.  If I had it written down I would include it here.  Mostly
has to do with checking
that all the power supplies are turned on, and that the ICD cable hasn't
fallen out, etc.  Then go
to the ICD "properties" and check the voltages it sees, and do the self
test.  I know you said the
power was on, but cables can break.

After all that, the second most likely problem is programming the PIC for
an oscillator you don't
have.  No clock, PIC won't run, MPLAB can't talk to the monitor, see above
explanation.

>To prove something, I loaded the Microchip hexadecimal
>file for the C source demonstration program that came
>with the PIC dem, and that all worked just fine.

I vote for the oscillator setting in the config word.  Open "Config bits"
and verify.

Barry

2005\12\02@155700 by Mario Mendes Jr.

flavicon
face
I had the same thing happen to me yesterday and it turned out that
everything was OK, except for the configuration of the oscilator.  The
ICD2 does not use the configuration bits from your code, but rather the
configuration set from the configuration menu.  The settings in both
places need to match.

Now, I don't know if EVERYTHING needs to match, but I set everything to be
the same just to be extra sure and it "majically" started working.

-Mario

{Quote hidden}

> -

2005\12\03@141110 by Tom Sefranek

face picon face


Mario Mendes Jr. wrote:

>I had the same thing happen to me yesterday and it turned out that
>everything was OK, except for the configuration of the oscilator.  The
>ICD2 does not use the configuration bits from your code, but rather the
>configuration set from the configuration menu.
>
Mine does!  And it complains when I have not set some config values.
Yes, you can override the values from the code, but it soes read my
config code at compile time.

>  The settings in both places need to match.
>
Not true in my experience.

The latest thing with the PIC18F4520 and this exact error is the BOR
must be turned off.

{Quote hidden}

>>-

2005\12\03@215211 by Grinder Smith

picon face
>I suspect the crosstalk is the problem for you.

>Have you updated your MPLAB? V7.22 is said to have
some problems with ICD2 for certain MCUs like 18F USB
parts.

I thank you sincerely for your suggestions.
(BTW, I already had that PDF in my archive - and I had
read it!)


Ah, I wish that it was so simple.
(It probably is, I just do not know what, yet!)


Nah, this is the exact same setup that I just bought
new.  It worked perfectly - very well - just a few
days ago.


I'm reading on through the list messages . . .

Grinder


               
__________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

2005\12\03@223535 by Grinder Smith

picon face
[Barry]
>>Target not in debug mode, unable to perform
operation
>>What is this?

>When you select debugger and program the chip, it
downloads a monitor along with your program.

Right.

Just as it did the previous - successfull! - time that
I did the same thing.  Many times.  Over and over.


>The error message means that either the debug bit
isn't enabled, or that it's unable to talk to that
monitor code.

So I thought, too.

I switched from 'debugger' to 'programmer' - I
definitely 'built all' each time - I programmed, the
thing works as it always did.

I switched from 'programmer' to 'debugger', I 'built
all', I programmed  (under the 'debugger' menu)  I got
the error.  Every time, now.  It worked before.  No
changes.

I have done this all successfully before with no
changes by me.  (What do I miss?)


>After awhile I formed a mental list of things to try
when the ICD won't play.  I say "mental" because mine
is inexact.  If I had it written down I would include
it here.

Thanks.  I am following along.


>Mostly has to do with checking that all the power
supplies are turned on, and that the ICD cable hasn't
fallen out, etc.

This is wise - and absurd!  We should probably all
admit that we have done something like this?

*My PIC dem board has power, it can be re-programmed
by my ICD2, and the program runs.

*The ICD2 has USB, lights up, connects, self-tests,
reads the PIC part number/version in the PIC dem
board, uses the Voltage, all of those usual things.


>Then go to the ICD "properties" and check the
voltages it sees, and do the self test.  I know you
said the power was on, but cables can break.

Yes.
I just re-did this again, both in 'programmer' and in
'debugger'.  All seems to be well.


>After all that, the second most likely problem is
programming the PIC for an oscillator you don't have. No clock, PIC won't run, MPLAB can't talk to the
monitor, see above explanation.

(Oh, no, not me, never!)
I have a configuration include file that explicitly
defines every configuration item.  This all worked
before.  I made a big deal out of it.  I like it!


>I vote for the oscillator setting in the config word.
Open "Config bits" and verify.

Yes, that's a killer.  Lamo Microchip really made that
awkward for me.  I will believe always that they knew
it and that they hid it.  My expensive system was
merely junk until I called them and got the solution -
they already knew of their problem.

As mentioned, it will never happen to me again because
I explicitly set every configuration item - and it has
all been tested and found to work.


Thanks for the input,

Grinder


               
__________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

2005\12\03@224942 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not in  debug mode, unable to perform operation

[Mario]
>I had the same thing happen to me yesterday and it
turned out that everything was OK, except for the
configuration of the oscilator.

Oh, that was my very first experience with my very
confusing new ICD2!  I am certain the Microchip has
handled that detail poorly.

I configure everything explicitly.  I learned.


>The ICD2 does not use the configuration bits from
your code, but rather the configuration set from the
configuration menu.  The settings in both places need
to match.

Curious!

What I see with my system is that after I 'build all',
MPLAB 7.21 uses my configuration, and _that_  is what
it shows in the 'configuration bits' window;  what
ever I configure in my exhaustive configuration
include file shows in the window.


>Now, I don't know if EVERYTHING needs to match, but I
set everything to be the same just to be extra sure
and it "majically" started working.

Fascinating!  I am glad that yours works.  I see no
easy way for these things to not match - lessn I alter
them.
(No self-destructive behaviour for me!)


Yes, this is gruelling!  I just did, re-did, re-did,
got sich of, all of the steps one more time.  I
started the MPLAB, I turned on the Voltage, I plugged
every thing in, I self-tested, I got the error . . .


Thanks!

Grinder


               
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

2005\12\04@000617 by shb7

flavicon
face
I haven't followed this thread from the beginning but I recently had a similar problem. What PIC is being used here?

Sean




2005\12\04@084438 by olin piclist

face picon face
Grinder Smith wrote:
>> The ICD2 does not use the configuration bits from
> your code, but rather the configuration set from the
> configuration menu.  The settings in both places need
> to match.
>
> Curious!

No, just plain incorrect.

>> Now, I don't know if EVERYTHING needs to match, but I
> set everything to be the same just to be extra sure
> and it "majically" started working.

You can wave a dead fish over it if you want, but likely you forgot a config
setting or two so that came from the default while the rest came from your
code.  A few versions of MPLAB ago there was a bug where it didn't correctly
pick up a config setting for some PICs, although I don't remember the
details.  I do remember it was fixed.  Maybe something similar happened with
a newer chip.  What PIC are you using?

> Yes, this is gruelling!  I just did, re-did, re-did,
> got sich of, all of the steps one more time.  I
> started the MPLAB, I turned on the Voltage, I plugged
> every thing in, I self-tested, I got the error . . .

Have you tried putting 47pF caps on the PGC and PGD pins as close to the
target PIC as possible?


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\04@124409 by Gerhard Fiedler

picon face
Grinder Smith wrote:

>> I vote for the oscillator setting in the config word. Open "Config bits"
>> and verify.
>
> Yes, that's a killer.

Note that for programming to work, you don't need any oscillator on the
chip. You can program a chip by simply connecting a bare chip properly to
the ICD2.

But for the debugger to work, the chip must be running -- which mainly
means that it needs power, proper reset handling (coordinated with the
ICD2) and an oscillator (internal or external). So the fact that it doesn't
work in debugging mode may mean that something with any of these is wrong.

I'd say you should check whether your chip does run while in debugging mode
(reset, oscillator). Maybe experiment with different oscillator modes (e.g.
use internal osc if your chip has one).

Gerhard

2005\12\04@141528 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not in debug mode, unable to perform operation

[Gerhard]
>Note that for programming to work, you don't need any
oscillator on the chip. You can program a chip by
simply connecting a bare chip properly to the ICD2.

Synchronous serial, the programmer clocks the PIC.


>But for the debugger to work, the chip must be
running -- which mainly means that it needs power,
proper reset handling (coordinated with the ICD2) and
an oscillator (internal or external).

E-mail sucks masively!

What am I reading, here?  Gerhard, your messages are
usually very accurate/correct, so I assume that this
one is.

If I connect my target board  (a new Microchip PIC dem
HPC Explorer with a new PIC18F8722 SMT'd at the
factory)  to a bat tree, it runs - as always.  It has
for several weeks.

My new MPLAB ICD2 programs the target board with
either the Microchip-compiled original demonstration
program or my assembly language program.  Every time. It always has, since I discovered Microchip's
way-too-Microsoft-like screw up with the configuration
bits.

My new MPLAB ICD2 always did do the debug function
before.


>So the fact that it doesn't work in debugging mode
may mean that something with any of these is wrong.

Yes?  Maybe?

Back to my first question from last week:

"ICD0083: Target not in debug mode, unable to perform
operation"

What the heck is this?

Microsoft never did any better with cryptic messages
and zero, 0, zero, 0, zero, none no help at all.  If
you are not already an expert on this absurdly arcane
narrow subject that most people will never see, the
so-called 'help' is nothing.


>I'd say you should check whether your chip does run
while in debugging mode (reset, oscillator). Maybe
experiment with different oscillator modes (e.g. use
internal osc if your chip has one).

(PIC18F8722)
It runs normally from battery or transformer.  With
ICD2 as programmer, it runs with 'release from reset'.

- Oh, I hate this!!!  With every message that I have
received on this lame subject, I have re-done, done,
did over, over done, the same thing.  Windholes -
world renowned as excessively tedious for any user
above beginner level.  Too many menus. -
I did it over and over again:
"ICD0083: Target not in debug mode, unable to perform
operation"

The lameness is killing me.


Thanks, Gerhard,

Grinder


               
__________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

2005\12\04@143604 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not in debug mode, unable to perform operation

Wow!  Is this more of that incorrect attribution
problem?

My name is Grinder Smith;  I did not type in what I am
attributed with typing in!

>Grinder Smith wrote:
>>> The ICD2 does not use the configuration bits from
your code, but rather the configuration set from the
configuration menu.  The settings in both places need
to match.


You may remember me as the guy that has created - and
tested to success - the world's most complete
configuration include file for the Microchip
PIC18F8722.


Grinder Smith is me;  I did type in "curious"!:

[Grinder Smith]
>>Curious!

[Olin]
>No, just plain incorrect.

>>> Now, I don't know if EVERYTHING needs to match,
but I set everything to be the same just to be extra
sure and it "majically" started working.

[Olin]
>You can wave a dead fish over it if you want, but
likely you forgot a config setting or two so that came
from the default while the rest came from your code.
A few versions of MPLAB ago there was a bug where it
didn't correctly pick up a config setting for some
PICs, although I don't remember the details.  I do
remember it was fixed.  Maybe something similar
happened with a newer chip.  What PIC are you using?

I am the guy suffering from Microchip's problem.

I paid a lot of money for a new MPLAB ICD2 and a PIC
dem HPC Explorer board with factory SMT'd PIC18F8722.
I do not own a dead fish.  I do not need one.  My new
equipment all worked the last time that I hooked it
up.


>>Yes, this is gruelling!  I just did, re-did . . .

>Have you tried putting 47pF caps on the PGC and PGD
pins as close to the target PIC as possible?

Good advice for a solderless breadboard?

No, and I will not.  This is new equipment, from
Microchip, and it all worked the last time that I
connected it.


Yes, E-mail sucks massively.  No matter how many times
I type in the same thing, it gets missed?


Thanks for the suggestions!

Grinder

PS:
More on Microchip and my configuration include file.

When it is not crashed, the ICD2 in 'debugger' mode
ignores whether I have set:

;CONFIG DEBUG =   ON         ; CONFIG4L = 300,006:
secret background debug setting! -------------- enable

;CONFIG DEBUG =   OFF        ; CONFIG4L = 300,006:
secret background debug setting! --------------
disable

On or off, commented - ignored.  ICD2 debugs.


               
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

2005\12\04@144209 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not indebug m ode, unable to perform operation

[Sean]
>I haven't followed this thread from the beginning but
I recently had a similar problem. What PIC is being
used here?


[Grinder Smith is me!]
In reply to a previous message, I just typed in:

"
You may remember me as the guy that has created - and
tested to success - the world's most complete
configuration include file for the Microchip
PIC18F8722.
"

- and -
"
I am the guy suffering from Microchip's problem.

I paid a lot of money for a new MPLAB ICD2 and a PIC
dem HPC Explorer board with factory SMT'd PIC18F8722. I do not own a dead fish.  I do not need one.  My new
equipment all worked the last time that I hooked it
up.
"

- and -
[about modifiying new equipment that already has
worked]
"
No, and I will not.  This is new equipment, from
Microchip, and it all worked the last time that I
connected it.
"

- and -
"
Yes, E-mail sucks massively.  No matter how many times
I type in the same thing, it gets missed?
"

Whew!  I now have absolute proof of this last bit.


Thanks for asking, Sean.

As I have typed in in the middle of the night, there
probably is a very simple solution.  All of this
equipment is new and all of this equipment worked . .
. the last time that it worked . . .

Grinder is tired of typing!


               
__________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

2005\12\04@151954 by olin piclist

face picon face
Grinder Smith wrote:
> Wow!  Is this more of that incorrect attribution
> problem?

Probably.  In a lot of your messages it's hard to tell what you wrote and
what you replied to.  If you put ">" in front of every line that you are
replying to you wouldn't have this problem.

> You may remember me as the guy that has created - and
> tested to success - the world's most complete
> configuration include file for the Microchip
> PIC18F8722.

Not really.  I've got important things to remember.  This isn't.

>> Have you tried putting 47pF caps on the PGC and PGD
>> pins as close to the target PIC as possible?
>
> No, and I will not.

Oh well then.  I've got better things to do.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\04@155141 by Grinder Smith

picon face
subject:  [PIC]:  ICD2 programming failure:  ICD0083:
Target not in debug mode, unable to perform operation

[Olin]
>>> Have you tried putting 47pF caps on the PGC and
PGD pins as close to the target PIC as possible?

[Grinder]
>>No, and I will not.

[Olin]
>Oh well then.  I've got better things to do.

Them's fightin' words!

What's up, Olin?

Why will you not use a meaninful quotation?  You
deleted the important part!  I am using a new
Microchip PIC dem HPC Explorer and it worked just fine
the last time that I used it.  I remain unconvinced
that it needs modifications.

Do you really expect that I need to modify Microchip's
proven circuit that worked perfectly the last time
that I used it?

Sheesh!


Grinder


               
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs

2005\12\04@160902 by olin piclist

face picon face
Grinder Smith wrote:
>>> No, and I will not.
>
>> Oh well then.  I've got better things to do.
>
> Them's fightin' words!

Excuuuuse me!!?  If I don't feel like spending my spare time continuing to
help someone who steadfastly refuses to follow my advice, that's completely
my business.  If you don't like it, you can have a full refund.

> Why will you not use a meaninful quotation?  You
> deleted the important part!

No, that was irrelevant to the point I was making.  Also, since you're the
one who can't get his system to work, I don't see how you're in a position
to tell me what is meaningful and what is not.  Like I said, if you don't
like it you can have a full refund.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\04@180523 by Gerhard Fiedler

picon face
> ICD2 programming failure:  ICD0083: Target not in debug mode, unable to
> perform operation

I just remembered that at some point MPLAB started to bring that message up
when trying to program while a program was running in the target. The
target must be held in reset while trying to program. Your descriptions
don't sound like it might be this, but I thought it couldn't hurt to
mention it. Make sure you put the device in reset before you try to start
debugging.


Grinder Smith wrote:

> [Gerhard]
>> But for the debugger to work, the chip must be running -- which mainly
>> means that it needs power, proper reset handling (coordinated with the
>> ICD2) and an oscillator (internal or external).
>
> If I connect my target board  (a new Microchip PIC dem HPC Explorer with
> a new PIC18F8722 SMT'd at the factory)  to a bat tree, it runs - as
> always.  It has for several weeks.

Ok, so the board (and the power supply, and the reset circuit, and the
oscillator) seem to be ok.

> My new MPLAB ICD2 programs the target board with either the
> Microchip-compiled original demonstration program or my assembly
> language program.  Every time. It always has, since I discovered
> Microchip's way-too-Microsoft-like screw up with the configuration bits.

Ok, so the most part of the ICD2 communication with the target board works.

Note that Olin is more experienced than I am (and than many are) with PIC
programming issues. I would not lightly dismiss his advice if I had a
problem.

> My new MPLAB ICD2 always did do the debug function before.

Does it still do it with a different program (like the demo program you
mentioned above)?

>> So the fact that it doesn't work in debugging mode may mean that
>> something with any of these is wrong.
>
> Yes?  Maybe?

Sorry if that sounded too vague, but that's how it is until we (you) know
what it was :)

I'd add here that it also may mean that something in the communication
between the ICD2 and your board may not be working; something that's unique
to the debugging mode. I don't know enough about the protocol between the
ICD2 and the device to be able to judge whether that's a real possibility
or not.

> The lameness is killing me.

Be patient. Think about all the good things in your life. Take your dogs
for a walk. Do it in pieces you can take :)

Gerhard

2005\12\04@193318 by Chen Xiao Fan

face
flavicon
face

>>I suspect the crosstalk is the problem for you.
>>
>Ah, I wish that it was so simple.
>(It probably is, I just do not know what, yet!)

To be honest, I actually do not like ICD2 very much
because of my experience with the 12F629 using the
debug header. However it is relatively cheap as a
debugger so we have to live with it. ;-(

It is not simple to solve the problem once it
start to get problems. There are many similar
reports in the Microchip Forum ICD2 section and that
is why they put up the pdf files I mentioned before.

Olin mentioned adding a 47pF capacitor. That is the
way to solve the crosstalk problems. I understand that
you are reluctant to solder extra components on a
Microchip supplied board (just like John Nall on the
other dsPIC board). Still this 47pF capacitor may do
the magic for you. Another possibility is the cable.
Most of my pervious problems with ICD2 comes down to
the cable. If you can, try another PC and another
cable to see if ICD2 starts to work. Try the
serial connection as well if you have not tried that.

It is frustrating experience but try calming down and
maybe you can solve the issue faster that way.

Regards,
Xiaofan

2005\12\05@011613 by Nicola Perotto

picon face

>>ICD2 programming failure:  ICD0083: Target not in debug mode, unable to
>>perform operation
>>    
>>
A question: this message appears in the Output window or in a dialog box?
I had the same problem with a warning: when checked the "Don't display
this warning again" in the dialog box the MPLAB does report the message
and than stop without making that it would have to do.
So, if the message appears in the output window go to Settings, Warnings
and re-enable the warning.
Regards
    Nicola


2005\12\05@061433 by Bob Axtell

face picon face
Grinder, my experiences with this error message are (in order of
importance):

1. The ground between the ICD2 and the breadboard needs to be
beefed up with an external ground. The easiest way to grab a good
ground on the ICD2 is actually to solder a #20 hi-flex wire to the USB
cable (exposed at the ICD2). Without this, you will have a flimsy #26
telephone wire. Attacfh the other end of the #20 wire to the breadboard.

2. The oscillator on the breadboard itself is not running (could be
anything).

3. Configuration improperly set when switching from programming mode
back to debugger mode.

Good luck!

--Bob

Grinder Smith wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
spam_OUTattachTakeThisOuTspamengineer.cotse.net .
1-520-777-7606 USA/Canada
http://beam.to/azengineer

2005\12\05@095509 by Buehler, Martin

picon face

i don't really have your setup, but i had strange problems with the
icd1. this thing always lost connection to the target.

looks like this was because of the wlan in my notebook. the icd seems to
work well as long as there's no wlan around.

tino

2005\12\06@160521 by Barry Gershenfeld

face picon face
Grinder,

I wanted to point out that I have had this message, too, lest you think you
are the only one in the world that it happened to.  In fact, that was the
result when I put MPLAB 7.22 on my laptop.  I gather from your messages
that it WAS working and that you haven't changed anything since it was
working (not even the software).

In my experience compiling the program causes the configuration bits to be
changed.  This is another thing MPLAB didn't used to do in the old days,
but it does now, and I'm forced to do my config setting in the CONFIG
(FUSES, actually) line of the source.   I still check the bits afterward to
see that they did what I told them to do.   But...I use C, not assembler,
and I think you have choices as to using the COFF file or some other, or
none at all.  Then there's the business of the config bits being in the HEX
file, which is good, and the fact that MPLAB overrides the debug bit
depending on the mode, which is...questionable.  Actually they've changed
that so I get a warning now, which is a step in the right direction, anyway.

Oh, as to email, and quoting...email is an inexact science, and hard to get
people to do the right thing, or even agree on what that might be, so the
best approach is to take what you get, interpret it as best you can, and
not rant too much about the method.  The quoting thing gets out of hand,
best thing to do after it gets too deep is to remove the
who-said-what.  After all, it's about the information, not the personalities.

Barry

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...