pic 18f4550 ICD2 programming problem

[fergcu]

Hi. I am working on a board which has been functioning fine using an ICD-2 to program my 18F4550 40-pin DIP, through the supplied header. Now, I am attempting to transfer this circuit to a PCB, using a 44-pin 44-pin TQFP chip (flat square surface-mount chip, but not the socket type). In this guise, the 'only' changes made to the design are the new connections between the PGC, PGD and MCLR pins, to the new programming connector. In this form, my board will not connect, and I get a warning "ICDWarn0020: Invalid target device id (expected=0x90, read=0x0)".

I am powering the board through the ICD-2, and there are no warnings about voltage levels. Any ideas? Apart from continuity testing, and voltage probes (which have all suggested a good board..).

Thank you,

fergus

 

[Russlk]

How are you making connection to the surface mount chip? and, why are there "new connections"? And, why is this not in the microcontroller forum?

 

[fergcu]

Hi, apologies for not putting this in the microcontroller forum. It didnt even occur to me... other things on my mind. Like getting this to work!

Anyway, the icd2 is connected to an AC162049 header board. I then used the flying leads to connect to a custom USB cable which plugs into the mini-usb-b port on my board. Vpp is connected to MCLR(pin18) , +5V is connected to +5V(pin7 + 28.), GND is connected to GND(pin 6 + 29), PGD is connected to PGD(pin17), and PGC is connected to PGC(pin 16).

I have enclosed the schematic as a .pdf.

Any thoughts would be much appreciated.

Kind regards,
Fergus

 

[eblc1388]

What have you done(i.e. not done) to the pin PGM, which is the LVP enable pin?

You need to pull it down so that the LVP mode is disabled during ICD2 HV programming.

 

[fergcu]

ahhh... I thought that if i left it floating, and disabled lvp in the config, it wouldnt need to be connected? is this not likely?
We actually try pulling it high, and enabling lvp, but we got the same error message.

Will try pulling it low and see what happens.

Ferg

 

[eblc1388]

ahhh... I thought that if i left it floating, and disabled lvp in the config, it wouldnt need to be connected? is this not likely?

Only if the LVP bit is disabled, so you thought.

But, a big BUT, regardless of the LVP bit setting, the PIC default to LVP enabled when it is fully erased, ready for programming. At this very moment, the configuration words have not even have a chance to be sent into the PIC to disable LVP. So the PIC sits there expecting data coming in via LVP mode.

The only way to disable LVP when a PIC is erased is to pull down the PGM pin.

 

[fergcu]

ok, have tried ppulling the LVP pin (rb5) down, but to no avail. Any other thoughts? have also raised R9 up to 20k (on the advice of someone on another forum), but this alos hasnt helped.
This is starting to worry me. I need the demonstrator by 24th feb... only 10 days to go.. aieee!
Anyway, if anyone has any other thoughts, they would be most welcome, and gratefully received.

kind regards

Fergus.

 

[eblc1388]

Remove the crystal of the PIC and test again. If good, the PIC is previously running internal codes and so will not enter programming mode.

Why the PIC is running depends on how you provide Vdd and MCLR signal. I'm not sure whether ICD2 can actively reset a running PIC(by pulling down the MCLR pin) to place it into programming mode.

Then troubleshooting your connections.

Starting from the mini-USB socket on your target board. Solder the signals wires out to try and read another PIC using ICD2. Remeber to select the correct chip in MPLAB first.

If good, ICD2, connecting cable, socket and signals are proven. You then consider your PIC is probably faulty.

 

[fergcu]

Hi, thanks for your thoughts.
Have traced all connects, and there are no connection/continuity problems.
We have reprogrammed a dip 4550 chip without any problems, so the ICD2 works.
We also have a similar circuit with a pic18f2550 chip, but we are getting exactly the same error message, so it is unliekly that the chip itself is faulty.
We have also removed the usb cable, and connected directly into little ports/vias in the circuit so that the distance between the icd2 and the circuit is ~7cm.

Any other thoughts? im wondering whether it might be a setting somewhere that were missing?

Thanks again.

Ferg

 

[eblc1388]

Have you tried removing the crystal?

 

[fergcu]

ok, its been solved...
It turns out that the lines going from RB7 and RB6 to RC5 and RC4 were causing problems. Essentially RC5 and RC4 were causing the query signal from the icd2 to be degraded so much that the chip wouldnt detect it. Temporarily split the line for programming and it detected it perfectly (well, i say perfectly... it turns out the 4550 is actually a dead chip after all, but it worked with the 2550).

Anyway, thank you for all your thoughts and advice EBLC.. It was much appreciated.

regards

Fergus.

 

[eblc1388]

I'm glad you have the problem solved.

Since you have mentioned RC4 and RC5 connections with PGD and PGC messing up the ICD2 signals, I looked at the 40-pin ZIF socket connection to my programmer and can confirm that RC4 & RC5 do indeed connected together with PGD and PGC(used for programming the 16F PICs) and this have not caused any problem during programming a 18F4455 using ICD2.

But alas mine is a ICD2 Clone, not the real one.