ICDU Programmer --> PIC16F676 bug???

[rock]

Hi All,
Just curious if anyone has tried to program a PIC16F676 with the ICD-U ??

In my attempt to (in circuit serially) program it, I:
-- open the ICD Control Program (v2.6) ... no prob...
-- press the 'Test ICD' button ... ICD Test passed ...
-- press the 'Test Target' button ... Target Test passed...
BUT.....
when I try to download the file an "ICD" window opens which says:
"The detected target name: PIC16F676 does not match the code's target: PIC16F76. Do you want to continue anyway?"

So... when I press the YES button, I see the program loading (small dialog), then verify, ... then ... a "Verification Results" window opens which (on a "Configuration Fuses" Tab) shows "actual data" as being: FC01
"expected data" as being: FC3F
The 2 lists of INTRC_IO, NOPROTECT, BROWNOUT, MCLR, NOMCLR, NOCPD, WDT, NOPUT are identical below in the columns for 'Actual' & 'Expected' though.

Now... although ICD Control Program does not indicate as much, I believe it is at this point that the ICD somehow revokes what was downloaded (?) or in some way does not allow my program to run (when I press the "Run Program" button).

My program is a just a short test program at this point (just turn on a couple of LEDs).

More specifically, the include file used in the program is <16F676.h>
but when I look at the <filename>.cof.txt flle, the following line is in there:
proc_type=0x0000676F [PIC16F76]

This leads me to believe that something inside the PIC Wizzard (or compiler) is inserting this line, causing the ICSP programmer (ICD) to never allow the program to run (due to the actual vs expected verify values for the config fuses...see above)????

If any one has experienced this, and / or if you know (from experience) that the compiler / ICD is capable of programmng a PIC16F676, I would appreciate any coments you could post.

Any Ideas???
thanks... rock

[Haplo]

From what I know PIC16F676 supports ICSP (In Circuit Serial Programming), but it does not support ICD (In Circuit Debugging) so you won't be able to use the ICD module to program it. If you look at the CCS header file for PIC16F676 you'll see it does not support DEBUG and NODEBUG fuse settings.

[rock]

Hi Haplo,
Thanks for your reply.
I was not trying to use any Debug features of the ICD-U, just the programmer part of it (/MCLR, PGD, PGC, +5, and Gnd) from it's socket.

Please correct me if I am wrong, but I thought the ICD could be used as a programmer for any "PICxxFxxx" parts (?).

Would I have been able to 'test target' (successfully) & later, download, and verify (albeit with the verify error noted in my post) the code I downloaded if the ICD-U could only program parts that have the 'in circuit debug' capability??

I still don't quite get it?????

Has anyone successfully used the ICD to program (ICSP) any PICs that don't allow DEBUG ??????

Thanks Again..... rock

[quote="Haplo"]From what I know PIC16F676 supports ICSP (In Circuit Serial Programming), but it does not support ICD (In Circuit Debugging) so you won't be able to use the ICD module to program it. If you look at the CCS header file for PIC16F676 you'll see it does not support DEBUG and NODEBUG fuse settings.[/quote]

[Mark]

From the sound of the error, it appears that either you have defined the target in code to be a 16F76 or you development enviroment thinks that it is a 16F76. Since the ICD is determining the device is an 16F676 there is a mismatch and thus the error.

[rock]

Hi Mark,

Yea... I've started from scratch a few times with the Wizard. My program is an additional 2 lines (that turn on a couple LEDs), and then a while(1).
I made sure that the target was selected correctly, that it generated the proper #include for the '676, did the I/O, and still no good on the verify.

That is.. I have looked at every target specific thing I could have done, and the "......coff.txt" file still ends up with the following line in it:
proc_type=0x0000676F [PIC16F76]

So... Is it whatever in the compile process creates the ...cof.txt file ???

Thanks for your reply...
Still going crazy on this end...
Any Ideas appreciated...... rock

[Haplo]

Hi Rock,
Please explain the connections between ICD and the PIC. What other components do you havee connected to the MCLR, PGC and PGD pins? Some common errors ar switched around PGC & PGD, and also too small pull-up resistor on the MCLR pin.

[Mark]

The ICD is detecting the right chip. The problem is that the software is created for a 16F76.

[rock]

Hey Haplo,


The PGC & PGD go directly (and only) to the programming connector (which is less than a foot from the ICD-U).

The /MCLR is pulled up by a (surf mount) 30k resistor to +5V (which is what the processor runs on), but the pin on the processor ALSO goes directly to the programming connector.

The power supply parts are surf mount switching regulator, caps, resistors, choke, catch diode etc..., and is good for about a half amp, and only powers the processor and the LEDs (except when programming, and then the ICD-U gets power from the GND & +5V on the prog connector).

I tested the LEDs prior to assembly (they and the connectors are the only non surf mount components), and they worked.... polarity on my board is correct etc.....

The supply reads 5.03 volts when I meter it.

Thanks again for your help.....
Still goin' crazy over here.......???
rock

[quote="Haplo"]Hi Rock,
Please explain the connections between ICD and the PIC. What other components do you havee connected to the MCLR, PGC and PGD pins? Some common errors ar switched around PGC & PGD, and also too small pull-up resistor on the MCLR pin.[/quote]

[rock]

Hey Mark,

I Think you got it..... I still have to get this job out, so I've got an email in to support at ccs.

Unless an answer comes up on this forum, I'll probably have to wait for morning (at ccs), and hopefully ccs support will reply....

Thanks again for all the help, and if you think of anything, I'll be listening.....
rock

[quote="Mark"]The ICD is detecting the right chip. The problem is that the software is created for a 16F76.[/quote]

[Mark]

Hi rock,

What device header file are you including? What comes after the #device in your code?

Mark

[rock]

Hi Mark,

The PIC Wizard wrote all the files except the part of main where I put the
output_low(LED2);
output_low(LED3);
while(1);
...etc...
[inside of the main braces]

In the (myfile).h file it created:
...
#include <16F676.h>
#device adc=8
..etc...

And after compiling, the list file contains:
...
//// Standard Header file for the PIC16F676 device ///////////
#device PIC16F676
#list

#device adc=8
#use...... etc ..... etc ...

The (myfile).SYM file contains:
Compiler Settings:
processor: PIC16F676
... etc ...

Yet...... (myfile).cof.txt contains:
...
proc_type=0x0000676F [PIC16F76]
...

Confused yet ????
So am I.
Thanks, though, for your interest & help..... rock


[quote="Mark"]Hi rock,

What device header file are you including? What comes after the #device in your code?

Mark[/quote]

[Guest]

I have the same problem with this chip and the ICD-S

"The detected target name: PIC16F676 does not match the code's target: PIC16F76. Do you want to continue anyway?"

I press yes here and then run button on the ICD app once its loaded and my program runs.

Make sure you remove the ICD=true from your header file.

I do hope they get this fixed soon.

[miko]

[Sigma]

Hi, Rock, Miko, Mike and anyone stuck into this problem b4,
Have you found out the reason for this problem.
I am having the same problem for PIC18F6622. The compiler thought it was a PIC16C622

[Mark]

That doesn't look like CCS output data to me? What compiler are you using? What programmer?, What software to run the programmer?