Problem for program 16f628A with Mplab icd 2 Verification problem

Hi all>

I have some troubles with programing the 16f628A with mplab icd2

i configured all bits configured, i don't have any pull up resistor in RB and RB7, the voltage suply is ok for Vdd and Vpp. the dispositive pass al the self test and the voltage have a rigth value. also i configured d bits configured in the program like this:

__CONFIG _HS_OSC & _WDT_OFF & _PWRTE_ON & _BODEN_OFF & _MCLRE_OFF _CP_OFF & _LVP_OFF & _DATA_CP_OFF

I tried with two tipes of communication with usb an with serial mode bu it continue wrong.

This is the error show in my output window.

Programming Target... ICDWarn0052: MPLAB ICD 2 cannot validate a target device. Please make sur that the target device is connected and properly powered. Select "OK" t continue, or "CANCEL" to abort the operation ..Validating configuration fields ..Erasing Part ..Programming EEPROM Memory ..Programming Program Memory (0x0 - 0x2F) ..Programming User IDs Verifying... ICDWarn0052: MPLAB ICD 2 cannot validate a target device. Please make sur that the target device is connected and properly powered. Select "OK" t continue, or "CANCEL" to abort the operation ..Program Memory ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val

0x2820, Val Read = 0x0) ICD0275: Programming failed. MPLAB ICD 2 Ready

in this text there are two warnings, the one is ICDWarn0052 and i chec all my connections ande the suply voltage of the pic and all are fine.

And the second warning is ICD0161 is something for the verification par of the icsp protocol, but i don't know what it read a cer value?

I don't what is the problem in my circuit or in the mplab icd configuration if anybody know something about this problem please i nee some help

Reply to
manfer1984
Loading thread data ...

It should tell you what it is expecting, and what it has found.

#ICDWarn0020: Invalid target device id (expected=0x83, read=0x0)

That warning message is from my ICD2 with nothing connected to it.

The ICD2 will report the following with no chip connected when you first connect to the ICD2;

#Connecting to MPLAB ICD 2 #...Connected #Setting Vdd source to MPLAB ICD 2 #ICDWarn0020: Invalid target device id (expected=0x83, read=0x0) #...Reading ICD Product ID #Running ICD Self Test #...Passed #MPLAB ICD 2 Ready

I don't really know what to tell you apart from the obvious such as having the pins hooked up properly. It's quite foolproof. I have had similar to you in the past and it has always been poor connections. An IC test clip is quite handy really as it means you don't have to stress the RJ11 on the ICD2.

Connections.

Reply to
Aly

might be a problem with the crystal. Have you tried reading a chip? Are you powering the target board from the ICD2?

Reply to
Anon

I don't know your device at all, but this looks odd to me - it's a series of bit masks ANDed with one another. If you're configuring a bit field, shouldn't you be ORing them together? (I guess it could be inverse logic...)

Possibly totally missing the point. but hey...

Steve

formatting link

Reply to
Steve at fivetrees

I have had similar problems that were caused by improper circuitry on the target board. It is helpful to look at the 3 active lines for clean waveshape and voltage levels. Capacitors and pullup resistors can cause problems. Particularly, the MCLR line pullup and capacitor (if any) should be connected via a signal diode so the ICD2 can apply the programming voltage (which is about 12-13 V). The other two lines are data and clock, and they should have clean waveforms during programming and verification. Finally, the target power supply and clock should be correct.

It is a good idea also to run the self test on the target board with the ICD2 from MPLAB. It will show the voltages it reads.

Paul

Reply to
Paul E. Schoen

Hi,

AFAIK on some PICs the PGM pin should be connected to gnd (by a resistor), even in high voltage programming mode. For the 16F628A this is RB4.

HTH Michael

Reply to
Michael Lange

Yes, it assumes inverse logic. Start off with all ones and remove selected bits. I don't know why Microchip selected that technique.

--
Thad
Reply to
Thad Smith

... to set not listed and unused bits high for default behavior?

Michael

Reply to
Michael Lange

EPROMs have (AFAIK) always been this way, where FFs mean it is blank. The first PICs were EPROM based, and followed this convention. Flash memory is also erased as logic 1 and programmed to logic 0.

The OpCodes for the Z80 and some other processors designated 00 as a NOP, so it was possible to reuse an EPROM by writing zeroes over a previous program and writing a new program in higher memory. Microchip PICs also follow this convention for OpCodes, which means you might be able to reprogram an OTP device.

Paul

Reply to
Paul E. Schoen

Paul E. Schoen schrieb:

thanks for illustrating my answer with some examples.

Michael

Reply to
Michael Lange

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.