Searching \ for '[PIC] Problem with ICD2 from Mchip' 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=icd
Search entire site for: 'Problem with ICD2 from Mchip'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Problem with ICD2 from Mchip'
2006\09\29@003724 by Shawn Wilton

picon face
OK, so I've been screwing around with this thing forever and I'm
frustrated.  I can't get it to recognize my 12f675 on my board (even though
another programmer I have recognizes it just fine).  So I said, OK, start
with something we know should work (bypass the custom cables).  So I plugged
it in to the PICDEM2+ that I ordered with my ICD and it still doesn't
recognize the device.  Help.

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\09\29@013902 by Shawn Wilton

picon face
OK, still having issues.  I'm getting the ICD to recognize something.  But
I'm getting this:

Setting Vdd source to target
ICDWarn0020: Invalid target device id (expected=0x7E, read=0x1FF)
ICDWarn0044:  Target has an invalid calibration memory value (0x3FFF).
Continue?

I have pic12f675 set in both mplab and of course the chip is a 675.  Ideas?
I've redone this darn cable atleast 12 times thinking I've done something
wrong, but I'm quite certain it is correct.


On 9/28/06, Shawn Wilton <spam_OUTblack9TakeThisOuTspamgmail.com> wrote:
{Quote hidden}

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\09\29@021056 by Bob Axtell

face picon face
Shawn, make sure that you are using an MPLAB version of MPLAB 7.4 or
later. The firmware that
gets installed for the ICD2 before that point was incredibly buggy. I
was getting the same foolishness.
Once I installed 7.4, the ICD2 cleared up IMMEDIATELY and I've had no
trouble since. I use two
ICD2s and the Wong Mini-ICD2 and a Wong Full USB ICD2 (my favorite).

Wong was the one that indicated that the MPLAB code for ICD2 was buggy
before that point.

I'm using WinXP with a very fast Intel processor.

--Bob

Shawn Wilton wrote:
{Quote hidden}

2006\09\29@022303 by Shawn Wilton

picon face
Hrm.  I'm using 7.42.  So should be good there.  Can you even use an ICD to
program a 12F675?  I'm beyond ready to send this thing back.  I have checked
and doubled checked my wiring, and it's all good.  The chip is known to be
good because I can program it with my K182 from diy and it runs my program
just "fine".

I really can't figure it out.  I try out the debugger with the header and it
fails to run the code.  I try the programmer and it fails to program because
even though the ICD tests validate, it can't figure out what the processor
is that it's speaking with.


On 9/28/06, Bob Axtell <engineerspamKILLspamneomailbox.com> wrote:
{Quote hidden}

> -

2006\09\29@030855 by Bob Axtell

face picon face
Shawn Wilton wrote:
> Hrm.  I'm using 7.42.  So should be good there.  Can you even use an ICD to
> program a 12F675?  I'm beyond ready to send this thing back.  I have checked
> and doubled checked my wiring, and it's all good.  The chip is known to be
> good because I can program it with my K182 from diy and it runs my program
> just "fine".
>  
I'm using 7.40.

Yes, I just programmed 4 of them last night. Works good. But only in
programmer mode, not ICD2 mode;
the PIC12F675/629 both do not have the internal debugger..

Yes, I love the K182, I own several, and my clients have a LOT of 'em.
> I really can't figure it out.  I try out the debugger with the header and it
> fails to run the code.  I try the programmer and it fails to program because
> even though the ICD tests validate, it can't figure out what the processor
> is that it's speaking with.
>  
Well, have you tried powering the device thru the external 9V access on
the ICD2. Perhaps you are not
properly powering it.. What do the self-tests say? Do they pass?

Look for a GND loop between the development PC and the product. I have
seen AC GND problems make
the ICD2 act like it lost its mind. The problem is usually caused by the
PC itself. At least, make sure
they both operate from the SAME AC mains branch. Course, an AC loop
might destroy the drivers in the
ICD2 as well.

Sounds like you may have broken it. There are a couple of TSSOP driver
chips that break a lot, I am told
(74HC125 & 74HC126). Sorry.

If I were you, get Kenny Wong's "Full USB ICD2" thru Ebay. He uses
stouter, easy to repair, DIP14 drivers.

His ICD2:

1. eliminates the Cypress chip; he uses an PIC18F4550 instead. The
cypress chip is cranky on some PCs.
Never noticed a USB problem with the 18F4550. But it accepts the
MPLAB-provided cypress driver that
MPLAB provides!

2. He uses the USB VDD, not an external 9V wallwart, with a jumper, not
a soft switch inside MPLAB.

3. He uses a 6-pin SIP header as well as the RJ12 connector. The SIP  
header makes a better GND
connection.

4. It costs about $70, which includes two 40P DIP programming stations
for the DIP-minded among us
(one is for DsPIC). MUCH better deal than the ICD2.

--Bob
{Quote hidden}

>> --

2006\09\29@032126 by Shawn Wilton

picon face
On 9/29/06, Bob Axtell <@spam@engineerKILLspamspamneomailbox.com> wrote:
>
>
>
> Yes, I just programmed 4 of them last night. Works good. But only in
> programmer mode, not ICD2 mode;
> the PIC12F675/629 both do not have the internal debugger..


How do you use the debug header?  Am I supposed to hook up the header in
place of the 8 pins on my IC?  Hardly convenient when I have a finished
board if that's the case.


>
> Well, have you tried powering the device thru the external 9V access on
> the ICD2. Perhaps you are not
> properly powering it.. What do the self-tests say? Do they pass?


Yes, the 9V adapter is plugged in to the  ICD and all the self-tests pass
just fine.

Look for a GND loop between the development PC and the product. I have
> seen AC GND problems make
> the ICD2 act like it lost its mind. The problem is usually caused by the
> PC itself. At least, make sure
> they both operate from the SAME AC mains branch. Course, an AC loop
> might destroy the drivers in the
> ICD2 as well.


There is no ground loop.  Only thing with AC power is the ICD.  The target
board is hardwired to a Li-Ion battery.

Sounds like you may have broken it. There are a couple of TSSOP driver
> chips that break a lot, I am told
> (74HC125 & 74HC126). Sorry.


Works just fine with my PICDEM2+ board.  But doesn't work worth **** with
these 12F675s.

I have this ICD in my possession.  Just can't figure out why it won't work.
Won't recognize the chip.  Just returns either a 0x000 or a 0x1FF or
something like that.  Can't remember and can't always duplicate it.

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\09\29@033415 by Shawn Wilton

picon face
HOLY HAM NUTS.  I don't know why, but my ICD just all of the sudden
recognized my 12f675.  I doubt it will last long, but WOW.

and it's programming!  Just wish I knew which prayer it was that fixed it!
--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\09\29@034753 by Bob Axtell

face picon face
Shawn Wilton wrote:
> On 9/29/06, Bob Axtell <KILLspamengineerKILLspamspamneomailbox.com> wrote:
>  
>>
>> Yes, I just programmed 4 of them last night. Works good. But only in
>> programmer mode, not ICD2 mode;
>> the PIC12F675/629 both do not have the internal debugger..
>>    
>
>
> How do you use the debug header?  Am I supposed to hook up the header in
> place of the 8 pins on my IC?  Hardly convenient when I have a finished
> board if that's the case.
>
>  
I've never used those things. I don't know how they hook up. I embed a
morse code beeper as a debug
tool in the PIC12F675, and I have it do a memory dump out an unused (or
temporariily assigned) pin.
So for those PICs that won't hook up to the ICD2, I use the morse code
beeper. I keep a pad of paper
handy to capture the dump.

Last shot. Maybe MPLAB7.42 has reverted to bad ICD2 code again? Can you
temporarily try MPLAB7.40
just for verification?

--Bob

{Quote hidden}

2006\09\29@034851 by Shawn Wilton

picon face
Yeah, didn't figure that would last long.  I disconnected the programming
adapter and wouldn't you know, now that I have plugged it back in it fails
to recognize the PIC again.  Seriously..

Another question.  I have to disconnect my ICD in order for the pic to run
on it's own.  Leave it plugged in and it leaves the PIC in some sort of
limbo preventing it from running.

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\09\29@035918 by Shawn Wilton

picon face
Hrm, strange.  I disconnect the PIC from the ICD at the ICD and it stops
running it's program.  I plug it back in and the ICD will recognize it.  But
only for a minute or two and then the PIC starts running it's program again
and the ICD fails to recognize the PIC.

Sound like damage, or settings?
--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\09\29@040909 by Bob Axtell

face picon face
Shawn Wilton wrote:
> Yeah, didn't figure that would last long.  I disconnected the programming
> adapter and wouldn't you know, now that I have plugged it back in it fails
> to recognize the PIC again.  Seriously..
>
> Another question.  I have to disconnect my ICD in order for the pic to run
> on it's own.  Leave it plugged in and it leaves the PIC in some sort of
> limbo preventing it from running.
>
>  
Yes, the ICD2 holds down the PCD and PGC pins. It has no class at all,
and an annoying trait.

Bad cable to the ICD2, maybe? But at least it indicates that it works
SOMETIMES.
I have trouble with those funky tiny teleco wires that that RJ12 uses.
Maybe one is poorly
connected. .

--Bob

2006\09\29@041742 by Shawn Wilton

picon face
I'm not sure.  I'm beginning to think something is faulty.  Most of the time
the darn thing is working now, but I have noticed if I power off the target
supply, then it won't program the chip.  I have to look at the spec since
I'm running the chip at 3.3V perhaps that's not enough juice to program.
Secondly, when it stops recognizing the chip, I sometimes have to either
just unplug it from the target, or completely reset the ICD.  Strange.  Wish
I could nail it down so I know if I have a faulty ICD, or something else.

On 9/29/06, Bob Axtell <RemoveMEengineerTakeThisOuTspamneomailbox.com> wrote:
{Quote hidden}

> -

2006\09\29@052312 by Bob Axtell

face picon face
Shawn Wilton wrote:
> Hrm, strange.  I disconnect the PIC from the ICD at the ICD and it stops
> running it's program.  I plug it back in and the ICD will recognize it.  But
> only for a minute or two and then the PIC starts running it's program again
> and the ICD fails to recognize the PIC.
>
> Sound like damage, or settings?
>  
Looks like an intermittent in a cable of the ICD2 itself.

--Bob

2006\09\29@052518 by Bob Axtell

face picon face
Shawn Wilton wrote:
> I'm not sure.  I'm beginning to think something is faulty.  Most of the time
> the darn thing is working now, but I have noticed if I power off the target
> supply, then it won't program the chip.  I have to look at the spec since
> I'm running the chip at 3.3V perhaps that's not enough juice to program.
>  
You know that you can't bulk erase the F675 (or almost any PIC) unless
the VDD is at 4.75-5.25V,
right?

--Bob

{Quote hidden}

>> --

2006\09\29@053504 by WH Tan

picon face
2006/9/29, Shawn Wilton wrote:

> I'm not sure.  I'm beginning to think something is faulty.  Most of the time
> the darn thing is working now, but I have noticed if I power off the target
> supply, then it won't program the chip.  I have to look at the spec since
> I'm running the chip at 3.3V perhaps that's not enough juice to program.
> Secondly, when it stops recognizing the chip, I sometimes have to either
> just unplug it from the target, or completely reset the ICD.  Strange.  Wish
> I could nail it down so I know if I have a faulty ICD, or something else.
>

I saw almost the same problem when I was working with the header...
and I noticed one important thing.  Everytime the communication was
lost, the calibration data was lost too.  Restoring the calibration
data will put the header back in order, most of the time.


Good luck.

--
WH Tan

2006\09\29@065910 by Jan-Erik Soderholm

face picon face
Shawn Wilton wrote :

> I have to look at the spec since
> I'm running the chip at 3.3V...

I've been following this (and your other thread) but I
do not remember seeing *that* piece of information !

You definitely have to check that the device supports
whatever you are doing at that voltage !

According the the Programming Specification, the
limits are :

VDD level for word operations, program memory :
2.0 - 5.5 V (PIC12F675-ICD)
4.5 - 5.5 V (PIC12F629/675)

VDD level for word operations, data memory :
4.5 - 5.5 V

VDD level for bulk erase/write operations, program
and data memory :
4.5 5.5 V

Regards,
Jan-Erik.



2006\09\29@124156 by Shawn Wilton

picon face
Yeah, I found the bit in the DS last night about needing 5V for
programming.  But you can run it at 3.3V.  So the system is still 3.3V and I
went ahead and set the ICD controls voltage box.  Works fine now.  But still
need to know how to hook up the header.


On 9/29/06, Jan-Erik Soderholm <TakeThisOuTjan-erik.soderholmEraseMEspamspam_OUTtelia.com> wrote:
{Quote hidden}

> -


'[PIC] Problem with ICD2 from Mchip'
2006\10\01@152433 by Andre Abelian
flavicon
face
Shawn,

Connecting ICD2 to PIC is really easy and  complicated if you have
hardware issue.
It sounds like your PGC and PGD pins have load. To make sure you do not
have impedance
problem put series resistor  and reduce capacitance  if you have any on
those pins.
Lets see your schematic first if you do not mind?
I use ICD2  every day they are very reliable and some times requires to
restart mplab or pc.
that could be even  windows  issue.

Andre




Shawn Wilton wrote:

>Hrm, strange.  I disconnect the PIC from the ICD at the ICD and it stops
>running it's program.  I plug it back in and the ICD will recognize it.  But
>only for a minute or two and then the PIC starts running it's program again
>and the ICD fails to recognize the PIC.
>
>Sound like damage, or settings?
>  
>

2006\10\02@024601 by Shawn Wilton

picon face
No, the pins don't have any load on them.

I followed peoples advice to pull the PIC from the board and actually put
the ICD in-circuit.  Put some wires on the SMD pads and now I am currently
trying to get the ICD debugger to work.  But it just gives me this output:

Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
Target Device PIC12F675 found, revision = Rev 0x2
ICDWarn0044:  Target has an invalid calibration memory value (0x0).
Continue?
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
Programming Target...
ICDWarn0044:  Target has an invalid calibration memory value (0x0).
Continue?
...Validating configuration fields
Connecting to debug executive
Entering Debug Mode
...Programming GOTO 0x00 command
ICD0083: Debug:  Unable to enter debug mode.  Please double click this
message for more information.
MPLAB ICD 2 Ready
Resetting Target
Entering Debug Mode
...Programming GOTO 0x00 command
Resetting Target
MPLAB ICD 2 Ready
MPLAB ICD 2 Ready
Entering Debug Mode
...Programming GOTO 0x00 command


All the self-tests pass.  I have this connected to the circuit.  I have
tried both with and w/o the target board powered and have also tried w/o the
debug header connected to the board.  I would think that even if the target
board were not connected, I would still be able to launch in to the debugger
and watch my code execute on the attached pic12f675 header board.

Any help or ideas, as always, appreciated.



On 10/1/06, Andre Abelian <RemoveMEandrespamTakeThisOuTditechnology.com> wrote:
{Quote hidden}

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\02@084927 by Rolf

face picon face
Shawn Wilton wrote:
{Quote hidden}

Hi Shawn.... others.

I have been doing battle with my ICD2 for the last couple of days as
well. I have been having intermittent problems, sometimes it works fine
for a few hours, then, it begins failing with one type of error (unable
to switch mode=TM, also unable to identify processor) or some such
message, it does that for a  few hours, then it does a message stack
very similar to your's, Shawn, with the ICDWawn0044, the ICD0083, and
sometimes the ICD0053 thrown in too.

I tracked mine back to the RJ11 connector in the ICD2. If I push the
ICSP cable hard in to the ICD2, it works, but if I tug gently on it so
it rests against the RJ11 retaining clip, it stops working. I think the
actual RJ11 socket is not "springy" enough, or something. But, you can
push the cable in until it clicks, then push it that extra millimeter
more..... works for me.

For the record, I don't have an oscilloscope, and I tracked this back by
putting LED's on the ICSP lines, and figures out that Vpp was not being
driven properly.... and playing with the cable caused the Vpp to go
high. ICSP works find while driving LED's off *each* line through 330Ohm
resistance....

This may or may not be your problem.

Rolf



2006\10\02@135941 by Shawn Wilton

picon face
Were your self-tests passing in mplab?


On 10/2/06, Rolf <learrEraseMEspam.....rogers.com> wrote:
{Quote hidden}

> -

2006\10\02@141637 by WH Tan

picon face
2006/10/3, Shawn Wilton wrote:

{Quote hidden}

Hi Shawn,

Did you try to restore the calibration memory location to a valid
value?  I think it's somewhere in the ICD2 setting dialogue box.


Best regards,

--
WH Tan

2006\10\02@142439 by Rolf

face picon face
Yes. All the time. With a 10F206 I was getting "Invalid OSCAL value"
messages when programming. With 18F2320 and 18F4620 I was getting other
funny messages, but the self-test always passed. When I get home I will
capture some of the messages.....

Rolf

Shawn Wilton wrote:
> Were your self-tests passing in mplab?
>
>
> On 10/2/06, Rolf <EraseMElearrspamrogers.com> wrote:
>  
>> Shawn Wilton wrote:
>>    


2006\10\02@150802 by Shawn Wilton

picon face
I know where it's at in the settings.  But what do I "restore" it to?



{Quote hidden}

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\02@170147 by Rolf

face picon face
Here's the log from the 18F4620 and 10F206, with my notes after ======
Note that all errors (apart from the invalid OSCAL value), are corrected
by pushing the ICSP cable deeper than just the "click" of the RJ11 cable.



======Everything working - program chip using ICD2 as debugger.
02-Oct-2006, 16:47:06

MPLAB ICD 2 Ready
Programming Target...
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0x47F)
...Loading DebugExecutive
...Programming DebugExecutive
...Programming Debug Vector
...Programming RSBUG
Verifying...
...Program Memory
...Debug Executive
...Debug Vector
...Verify Succeeded
Programming Configuration Bits
.. Config Memory
Verifying configuration memory...
...Verify Succeeded
Connecting to debug executive
...Programming succeeded
02-Oct-2006, 16:47:24

======Gently pulling the RJ11 ICSP connector so that it is not seated
quite as deeply in the ICD2, then try program...
MPLAB ICD 2 Ready
Programming Target...
ICDWarn0052: MPLAB ICD 2 cannot validate a target device. Please make
sure that the target device is connected and properly powered. Select
"OK" to continue, or "CANCEL" to abort the operation
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0x47F)
...Loading DebugExecutive
...Programming DebugExecutive
...Programming Debug Vector
...Programming RSBUG
Verifying...
ICDWarn0052: MPLAB ICD 2 cannot validate a target device. Please make
sure that the target device is connected and properly powered. Select
"OK" to continue, or "CANCEL" to abort the operation
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val =
0xEF1C, Val Read = 0x0)
ICD0275:  Programming failed.
MPLAB ICD 2 Ready

======Clicking the "Reset and connect to ICD2" toolbar button
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
ICDWarn0020: Invalid target device id (expected=0x60, read=0x0)
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready

======Pressing the "Run" Debug button
ICD0083: Debug:  Unable to enter debug mode.  Please double click this
message for more information.
Running Target
ICD0083: Debug:  Unable to enter debug mode.  Please double click this
message for more information.
ICD0069: Debug:  Unable to run target
MPLAB ICD 2 Ready

======Running the "Self Test" button from the ICD2 Settings dialogue.
Running ICD Self Test
...Passed


======
======
======Then, with the 10F206....
======
======

Connecting to MPLAB ICD 2
...Connected
ICDWarn0030: MPLAB ICD2 is about to download a new operating system.  If
MPLAB IDE is just starting, it will appear to "hang" at the splash
screen.  Please be patient.  MPLAB IDE will finish it's intialization
after the OS is downloaded.  (Note:  You may wish to select to ignore
this warning in the future.)
Downloading Operating System
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
ICDWarn0044:  Target has an invalid calibration memory value (0xFFF).  
Continue?
...Reading ICD Product ID
Running ICD Self Test
...Passed
...Download Operating System Succeeded
Setting Vdd source to MPLAB ICD 2
ICDWarn0044:  Target has an invalid calibration memory value (0xFFF).  
Continue?
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready

======Programming the chip while the connector is "deep".
Programming Target...
ICDWarn0044:  Target has an invalid calibration memory value (0xFFF).  
Continue?
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0xFF)
Verifying...
...Program Memory
...Verify Succeeded
Programming Configuration Bits
.. Config Memory
Verifying configuration memory...
...Verify Succeeded
...Programming succeeded
02-Oct-2006, 16:55:55

MPLAB ICD 2 Ready


======Programming the chip when it is *not* deep.
Programming Target...
ICDWarn0052: MPLAB ICD 2 cannot validate a target device. Please make
sure that the target device is connected and properly powered. Select
"OK" to continue, or "CANCEL" to abort the operation
ICDWarn0044:  Target has an invalid calibration memory value (0x0).  
Continue?
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0xFF)
Verifying...
ICDWarn0052: MPLAB ICD 2 cannot validate a target device. Please make
sure that the target device is connected and properly powered. Select
"OK" to continue, or "CANCEL" to abort the operation
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val =
0x25, Val Read = 0x0)
ICD0275:  Programming failed.
MPLAB ICD 2 Ready


======Clicking the "Reset and connect to ICD2" toolbar button
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
ICDWarn0044:  Target has an invalid calibration memory value (0x0).  
Continue?
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready

======Re-seating the RJ11 connector and Clicking the "Reset and connect
to ICD2" toolbar button again (note change in calibration value error)
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
ICDWarn0044:  Target has an invalid calibration memory value (0xFFF).  
Continue?
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready


Rolf

Rolf wrote:
{Quote hidden}

2006\10\02@230207 by WH Tan

flavicon
face
Shawn,

If you have recorded the calibration value before it was lost, you can check
the box "Allow ICD2 to program calibration memory" and put the value you
recorded in the text box there.  If you didn't record it, I think 0x80 is a
good starting point.  After that the calibration memory will be restored the
next time you program the device/header.


Best regards,

WH Tan



{Quote hidden}

2006\10\03@000610 by Shawn Wilton

picon face
What is the calibration memory for?

I tried setting it and it did not make a change.  I still can't get this
header to do anything.  Does anyone know where I can get the image for the
header, or are they setup so you can't write to them?



On 10/2/06, WH Tan <RemoveMEtanwhspam_OUTspamKILLspamnotes.src.global.sharp.co.jp> wrote:
{Quote hidden}

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\03@003656 by Shawn Wilton

picon face
OK,
this is what I get when I try to put *JUST THE HEADER* in to debug mode:

Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
Target Device PIC12F675 found, revision = Rev 0x2
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
Programming Target...
...Validating configuration fields
Connecting to debug executive
Entering Debug Mode
...Programming GOTO 0x00 command
ICD0083: Debug:  Unable to enter debug mode.  Please double click this
message for more information.
MPLAB ICD 2 Ready
Resetting Target
Entering Debug Mode
...Programming GOTO 0x00 command
Resetting Target
MPLAB ICD 2 Ready
MPLAB ICD 2 Ready
Entering Debug Mode
...Programming GOTO 0x00 command

This is just the header, no target circuit attached.  Ideas?  I'm fresh
out.  ICD seems to be flaky as all heck.  Sometimes it sees the header,
sometimes it doesn't.  WHY?

I would really love to be able to use this darn thing, so if anyone has had
similar troubles with a header and knows ANYTHING, please share.  Feel free
to contact me off list if you're too shy to reply to the list itself.
--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\03@030053 by Shawn Wilton

picon face
I just noticed the debug exec on my ICD has no version info.  Could this be
the cause of my problems?  If so, how would I restore it on this little
header.

If anyone wants a screen shot of what I mean, LMK and I will send you a
little jpg.  I don't want to send it to the whole list though.

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\03@033818 by Jan-Erik Soderholm

face picon face
> What is the calibration memory for?

See the datasheet.

Jan-Erik.



2006\10\03@034455 by Shawn Wilton

picon face
I did a search on both the mid-range manual and the data sheet.
"calibration memory" was not found.  Hence the question.

Perhaps you could tell me where in the datasheet I should look?


On 10/3/06, Jan-Erik Soderholm <RemoveMEjan-erik.soderholmTakeThisOuTspamspamtelia.com> wrote:
>
> > What is the calibration memory for?
>
> See the datasheet.
>
> Jan-Erik.
>
>
>
> -

2006\10\03@035715 by Jan-Erik Soderholm

face picon face
Shawn Wilton wrote :

> "calibration memory" was not found...

Look for "calibration".

I'm not going to look up the actual page
number for you. I *know* it's there... :-)

Jan-Erik.



2006\10\03@043139 by Wouter van Ooijen

face picon face
> I'm not going to look up the actual page
> number for you. I *know* it's there... :-)

but probably not in the midrange reference manual: IIRC that dcoument is
older than the first PICs with calibration memory.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\10\03@045738 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> > I'm not going to look up the actual page
> > number for you. I *know* it's there... :-)
>
> but probably not in the midrange reference manual:
> IIRC that dcoument is older than the first PICs with
> calibration memory.

Since I specificaly wrote "See the datasheet",
that shouldn't be any issue.

Jan-Erik.



2006\10\03@052914 by Wouter van Ooijen

face picon face
> > > I'm not going to look up the actual page
> > > number for you. I *know* it's there... :-)
> >
> > but probably not in the midrange reference manual:
> > IIRC that dcoument is older than the first PICs with
> > calibration memory.
>
> Since I specificaly wrote "See the datasheet",
> that shouldn't be any issue.

The OP indicated that he had searched the MRM, which is often a good
place to look, but indeed as you pointed out not in this case.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\10\03@075202 by WH Tan

picon face
2006/10/3, Shawn Wilton wrote:

> I just noticed the debug exec on my ICD has no version info.  Could this be
> the cause of my problems?  If so, how would I restore it on this little
> header.


Shawn,

I just confirmed with mine, with MPLAB v7.41, it said 01.00.04.00 for
debug executive.

Just to confirm, as someone already pointed out in recent message, did
you pull up GPIO3 to Vdd?  I means when the header is in your target
circuit.  And if you use only the header alone, I think you might not
get anything out of it since GPIO3 is not pulled to Vdd.


Best regards,

--
WH Tan

2006\10\03@114747 by Shawn Wilton

picon face
How do you tell which pin on the ICD chip is GPIO3?  I would think that you
could use the header outside of your circuit, or that it should at least
enter debug mode...?


On 10/3/06, WH Tan <EraseMEwhsiung.myspamspamspamBeGonegmail.com> wrote:
{Quote hidden}

> -

2006\10\03@114755 by Shawn Wilton

picon face
I checked VPP and it's being pulled up to at least 13V.  Is that the gpio3
you're talking about?  Remember this is a header board and not on a 12f675
since you can't have one on the board.


On 10/3/06, Shawn Wilton <RemoveMEblack9KILLspamspamgmail.com> wrote:
{Quote hidden}

2006\10\03@122839 by WH Tan

picon face
On 10/3/06, Shawn Wilton wrote:

> How do you tell which pin on the ICD chip is GPIO3?  I would think that
> you could use the header outside of your circuit, or that it should at least
> enter debug mode...?

With Pin 3 of the 14-pin -ICD device being mapped to pin 1 of the real
F675, then GPIO3 of the real F675 is pin 4, which is should be pin 6
of the -ICD device.  You can have a look at page 7 of DS51292L.



> I checked VPP and it's being pulled up to at least 13V.  Is that the gpio3
> you're talking about?  Remember this is a header board and not on a 12f675
> since you can't have one on the board.

What do you means with Vpp?  Pin 1 of RJ11?  Note that Pin 1 of RJ11
goes to pin 2 (~ICDMCLR) of the -ICD device, which is NOT GPIO3.

I see there might be some confusion here:  At the -ICD device pin 3 -
pin 6  and pin 9 -pin 12 are meant to be mapped to your target
circuit.  Since you're using external MCLR/GPIO3 (don't confuse this
one with the Vpp/~ICDMCLR), you have to pull it to Vdd.

That is one of the limitation of the -ICD header - we have been ripped
off the right to use internal MCLR :)



Best regards,

--
WH Tan

2006\10\03@150721 by Shawn Wilton

picon face
Yeah, I've seen that worthless document.  I have the 9V adapter plugged in
to the ICD, so I don't think I need to apply an external VDD so long as I
set the ICD to power the target (which is unconnected).  Should still go
ahead and connect.

Iff VDD were not powered wouldn't the ICD fail to connect and fail the
self-tests as well?


On 10/3/06, WH Tan <spamBeGonewhsiung.mySTOPspamspamEraseMEgmail.com> wrote:
{Quote hidden}

Aren't all 8 pins supposed to be mapped to the target as the ICD header
takes the place of any chip you would otherwise have installed on the board?

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\03@155103 by WH Tan

picon face
2006/10/4, Shawn Wilton wrote:

> Yeah, I've seen that worthless document.  I have the 9V adapter plugged in
> to the ICD,

This is fine.

> so I don't think I need to apply an external VDD so long as I
> set the ICD to power the target (which is unconnected).

Then you have been applying Vdd to the header.

>  Should still go
> ahead and connect.

I would suggest you just connect a 10K resistor and do the test
without plug it into your target.  That's the way I tested it this
evening.  I don't have any target circuit at the moment.  In this way
it would at least eliminate other possibilities.




> Iff VDD were not powered wouldn't the ICD fail to connect and fail the
> self-tests as well?

No Shawn.  The Vdd exist on the header.  You power it from your ICD2
with the 9V external power supply.  This is fine.  But the problem is
you'll still need to pull the 'actual MCRL' to Vdd.  Let me explain
this in deep.

Think of the header as 2 part.  Part A: the extra pins that designed
for ICD2 communication and setting up some options (like jumper, some
other type of headers don't have jumper).  This part also include the
~ICDMCLR, which has taken some reposibility (Vpp) off the usual
MCLR/Vpp pins as you will find in usual ICD capable device, like the
high pin count PIC.

PART B: The 8 pins that are mapped to emulate the actual F675.  For
this part to work, you have only one option regarding the
configuration of the MCLR.  It must be configured as MCLR. Not a true
MCLR as some of its responsibility (Vpp) has been taken by PART A
(~ICDMCLR),    BUT it must still be pull-up to Vdd, as you did with a
normal PIC's MCLR.  Without that the PIC won't run, and the ICD2
communication can't be established. Can you just find a 10k resistor
and connect it to the header to perform the test.  It sould be joint
to pin 3 and pin 6 of the -ICD.  You can find the PCB trace and join
it at the top side of the PCB.  Or connect the 10k resistor at your
target and plug the header in.


Best regards,

--
WH Tan

2006\10\03@170622 by Shawn Wilton

picon face
Yeah, now that I understand what you're saying, I'll give it a shot this
evening.  Thank you.


{Quote hidden}

--

Shawn Wilton (b9 Systems)
http://b9Systems.com  <- New web page

2006\10\03@172713 by Xiaofan Chen

face picon face
On 10/3/06, WH Tan <KILLspamwhsiung.myspamBeGonespamgmail.com> wrote:
{Quote hidden}

I do not think it is a good idea to put the 10k resistor at the top
side of the PCB. It should be in the target board.

I've used the ICD2 with 12F629 (using the same header as 12F675,
use the jumper setting to disable the ADC inside 12F675). I can
say it is a pain to use. There are many limitations to take note.
It is still usefull but limited.

>From MPLAB V7.42 ICD2 Help:
PIC12F629/675, PIC16F630/676, PIC16F627A/628A/648A Limitations
PIC12F675-ICD - PIC12F629/675

Debugger Limitations:
Device-ICD/ICE Limitations
You cannot single step through an interrupt.
Devices cannot be programmed or read while GP1/RA1 is high (Vih). Move
circuitry that makes GP1/RA1 high to another I/O pin during
development.
Programming these devices while debugging may be slower as these
devices do not have row erase capability.
Programmer Limitations
Program Memory standard flash

Device-ICD/ICE Limitations
For some devices, only the ICD/ICE version of the device (e.g.,
PIC12F629-ICD) can be used to debug with MPLAB ICD 2.
ICD/ICE devices must be used with a header board. See the Header Board
Specification (DS51292).
Only ICD/ICE devices can be programmed using the MPLAB ICD 2 Header.
Use the Universal Programming Module (AC162049) to program regular
devices.
ICD/ICE devices must be clocked (internally on INTOSC or externally on
OSC1) and have MCLR high to communicate with the MPLAB ICD 2.
A breakpoint cannot be set on a GPIO instruction. Since MPLAB ICD 2
I/O is through bits 6 and 7 of GPIO, setting a breakpoint on a GPIO
instruction will cause communication problems.

Programmer Limitations
Care should be taken when programming the PLL.
For all devices with EEPROM memory, Erase operations will also erase
EEPROM memory.
If your code makes use of port pins that correspond to Clock and Data
pins in programming mode, you may not be able to reprogram your
device. See Warning 0033 for more information.

Regards,
Xiaofan

2006\10\04@025345 by Shawn Wilton

picon face
Hot damn.  Putting that resistor in place did the trick.  THANK YOU TO
EVERYONE IN THIS THREAD.

Here's to hoping I can get some work done before this thing dies on me.



On 10/3/06, Xiaofan Chen <EraseMExiaofancspamEraseMEgmail.com> wrote:
{Quote hidden}

> -

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