[SOLVED] Project to replace CY7C64613 in the ICD2

[JQL]

Ok. Here I am again. RA3 = 2.4V - VPP-GEN=9.34V
.............................
just a little update, now I'm having these readings:
**broken link removed**

Hello Gonza

I'm always giving your clone my attention.

"First of all check the voltage using multimeter on 18F877's RA3 pin (5th), and on the VPP-GEN rail.", potyo's word, is important.

First is to affirm the state of detection system. Here inconsiderate of that for the moment, if VPP_GEN's and VPP's values are correct.
If VPP_GEN's value by multimeter is approximately equal to VPP's value by MPLAB ICD2, then show that for us, the scale relation of 2.2k and 6.8k is normal, and MPLAB ICD2's detection is right.
Or else, check these resistors.

VPP_GEN / V_RA3 = (6.8k + 2.2k) / 2.2k = 9 / 2.2
(R5=6.8k, R11=2.2k in your Protel SCH)

if VPP_GEN = 13.0v, then V_RA3 = 3.18v
if V_RA3 = 2.4v, then VPP_GEN = 9.82v

Second is to correct VPP_GEN's value.
Check 10k, 1.5k, 2.2k resistors and other doubted place.
(R4=10k, R9=1.5k,R10=2.2k in your Protel SCH)

I wish you success.

JQL
2007.08.12

 

[Gonzakpo]

Hi JQL. Thanks for your help.

First question: What's the diference between "Targen Vpp" and "MPLAB ICD 2 Vpp" (the ones that appear in MPLAB settings). I guess the "MPLAB ICD 2 Vpp" corresponds to the VPP-GEN in potyo's design because I'm getting good readings. Using a multimeter to measure VPP-GEN I get more or less what MPLAB IDE shows under the tag of "MPLAB ICD 2 Vpp" so I guess the detection circuit is working fine.
I rechecked the everything on the PCB! The resistances are just fine.

The problem here (I think) is that MPLAB doesn't want to adjust this tensions because for MPLAB they are fine! (My ICD2 passes the "self-test"). So I guess that I'll never get 13V if MPLAB doesn't want to. Maybe this voltages are ok and the problem is somewhere else.

For now, my icd2 recognizes the target device id (18F4550), connects and pass the self-test. But later, for example, when I try to erase the uC says "Erase Succeded" but when I do the "Blank Check" it fails.

Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
Target Device PIC18F4550 found, revision = a3
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
Erasing Target Device...
...Erase Succeeded
MPLAB ICD 2 Ready
Blank Checking...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x48, Expected Val = 0xFFFF, Val Read = 0x00)
...Device not blank

What calls my attention is that the "Val Read = 0x00" is very random. Sometimes I get 0xFF sometimes 0x00, or other things..

Can be this fault of the low voltages? or it's something else?

Please, help me with ideas. I really don't know what to check now. I've already looked for short circuits or broken connections but I found NOTHING. Everything seems alright.
Could it be the loader I used for the 16F877A ?...I used the one in here: http://www.icd2clone.com/wiki/Main_Page

For the 18F4550 I used the one posted on potyo's forum (the latest one).

Thanks.

******************************************

I just did another little test. I removed the 74HC4066 from the socket and short circuit the corresponding pins in the socket in order to simulate what hc4066 should do. Nothing changed. I still can't erase and blank-check the target so I guess the HC4066 was working fine.

Another thing that calls my attention is that in MPLAB under the programmer tag (when I choose it to act like a programmer of course), MPLAB always holds the target in reset. When I choose to release from the reset, It does, but when I do another thing (like erase, or read) it holds it in reset again. Is this normal? I guess yes, but don't know why.

Thanks.

*********************************************
Yet another little test....
Now I tried to erase the uC using an incredible SHORT cable and nothing. Everything remains the same. I guess is the ****** voltages fault...

 

[Gonzakpo]

I've been re-reading the whole topic.

I'm using a 220uH choke..could be this the problem of the low voltages?..Maybe I'm demanding too much current to the USB port. I have really no idea, I'm just guessing based on what "Bleska" said here:

 

[abrahamq]

louis99
about 18F4550 corruption look my post here


best regards
stroma

I check the post you gave me and it doesn't help.
1) I use MPLAB 7.6 and not 7.4 but I don't think it's related.
2) The configuration bit is correct and respect the "Table write protect boot" Disable.

Now, when I plug the ICD2 clone , windows doesn't reconize it.
When I plug and unplug and plug the ICD2 original, no PB.

When the ICD2 is screw, it permanently.

Hi to all!

I find many times that PIC18F4550's contents have been rewritten, the ICD2.5 has become a "Unknown Device".

JQL 2007.07.18

Best regards Louis.

Hi louis99 and JQL


Mine, PiCs RevB, have the same problem (18f4550 data being corrupted now and again, roughly 2 out of 10 times, causing by unplugging usb connection).

I have solved this problem even though I can't explain why it works.

Here is how.
modify 18f4550 bootloader hex (bottom of the file) to disable MCLR
from
:0E000000240F3900008180000FC00FE00F4078
to
:0E000000240F3900000180000FC00FE00F40F8

before flashing it with this modified hex file

'WRITE Protect' all area of code space including boot area. no protection for the reading and data area also no protection.

this can be done by setting the configuration (i use PICkit 2 clone, yours can be a different programmer).

I have attached(uploaded) this modified hex file 18F4550_bootFinal120807.hex (created on 12 August 2007) you can use straight away.

Good luck.

Please give me a feedback because I don't know this will solve anyone else problem in this area. Mine seem to be solved.


Now my other problem to solve next is to get thic icd2 to supply vdd to target. If any one have any success please help, help and help.


Regards

 

[JQL]

Hello Gonza

Erasing Target Device...
...Erase Succeeded

It reported only that, MPLAB ICD2 executed "Erase" operation, but didn't execute "verifying" operation.

Blank Checking...
...Program Memory
...Device not blank

It reported a true state, Program Memory is not blank.
That is, due to the VPP voltage too low, "Erase" operation no succeeded actually.

I suggest that, to give the VPP voltage your attention.
Move MCP41010 out of it's socket.
Then do following examinations by multimeter for MC34063.

Do not anything. R10(2.2k) is disconnected and is not reacting.
Here MC34063's output voltage VPP rest with R4(10k) and R9(1.5k), and is minimum.

VPP_min = 1.25v * (1 + R4/R9) = 1.25 * (1 + 10k/1.5k) = 9.58v

Short circuit DPOT1 and DPOT2, make sure That R10(2.2k) is parallel connected to R9(1.5k).
Here MC34063's output voltage VPP rest with R4, R9 and R10, and is maximum.

VPP_max = 1.25v * (1 + R4/(R9*R10/(R9+R10)) = 1.25 * (1 + 10k/(1.5k*2.2k/(1.5k+2.2k))) = 15.26v

Base on above examinations, validate that, if MC34063 can work normally.

Victory is at hand.
胜利就在眼前。
JQL
2007.08.13

 

[terka]

Well, some news. Now it's detecting the target but it doesn't program it or anything. I tried to erase a 18F4550 and when I do the blank-check it fails.

Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
Target Device PIC18F4550 found, revision = a3
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
Erasing Target Device...
...Erase Succeeded
MPLAB ICD 2 Ready
Blank Checking...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x48, Expected Val = 0xFFFF, Val Read = 0xFF)
...Device not blank

Probably is because the low voltages... Potyo help me please!! (or anyone else!)

Hi, after erase, read memory, then verify..

Bye

 

[JQL]

Hi louis99 and JQL
I have solved this problem even though I can't explain why it works.

Here is how.
modify 18f4550 bootloader hex (bottom of the file) to disable MCLR
from
:0E000000240F3900008180000FC00FE00F4078
to
:0E000000240F3900000180000FC00FE00F40F8

I have attached(uploaded) this modified hex file 18F4550_bootFinal120807.hex (created on 12 August 2007) you can use straight away.

abrahamq
Thank you for your special reply.

I downloaded the 18F4550_bootFinal120807.hex.
But I don't know that, why modified
not to
:0E000000240F3900000180000FC00FE00F40F8
to
:0E000000240F390000018000008000000F4036

Regards
JQL
2007.08.14

 

[abrahamq]

Hi louis99 and JQL
I have solved this problem even though I can't explain why it works.

Here is how.
modify 18f4550 bootloader hex (bottom of the file) to disable MCLR
from
:0E000000240F3900008180000FC00FE00F4078
to
:0E000000240F3900000180000FC00FE00F40F8

I have attached(uploaded) this modified hex file 18F4550_bootFinal120807.hex (created on 12 August 2007) you can use straight away.

abrahamq
Thank you for your special reply.

I downloaded the 18F4550_bootFinal120807.hex.
But I don't know that, why modified
not to
:0E000000240F3900000180000FC00FE00F40F8
to
:0E000000240F390000018000008000000F4036

Regards
JQL
2007.08.14

Hi JQL

to clear the confusion, I now upload the original 4550 boot for you.
you change that particular line
from
:0E000000240F3900008180000FC00FE00F4078
to
:0E000000240F3900000180000FC00FE00F40F8

then, within the pic programmer software, set configuration bits to protect the code from being written. The electrical fluctuation while unplugging usb cable can cause the pic to get to the programming mode and start writing garbage into the code area especially the boot section(I guess).

This configuration setting will furthur change that line
from
:0E000000240F3900000180000FC00FE00F40F8
to
:0E000000240F390000018000008000000F4036

You just use the 18F4550_bootFinal120807.hex you download as is. That line is shown
:0E000000240F390000018000008000000F4036
already
So just flash it (18F4550_bootFinal120807.hex) in your 18f4550 using your 'hardware/software pic programmer'. Tell us if this solve your usb chip corruption problem.

Hope this will clarify it.

Regards
AbrahamQ

 

[alunaro]

I have tested my circuit in debug mode (tested with 16f877a target)

It works perfectly with MPLAB 7.6, debugging without problems.

I attach the source that i wrote (it is not nice, only for testing purporses). It has
notes about ICD2 debug mode and how to set it. Anyway, you can read the code

 

[elec_gu]

Hello,
I have a USB ICD2 clone and it doesn't seems to work with PICs 24FJ series.
The ICD2 clone is ok and it should work with 3.3v parts.
I'm programming the target PIC with another ICSP programmer and everything is ok too.
But when I try to do it with ICD2 it fails: Invalid target device id ... etc.
Please help me.
thanks

 

[alunaro]

Which icd2 clone have you made? PICS, Potyo, ... ?
I only can talk about PICS's that is which i made. It doesn't work with 3.3v devices.
You need a level adaptor 5V-->3.3V for the PICS ICD2 (revB). Teskan and picnoobie posted some variant of
PICS to support 3.3v devices and a simple level adaptor.

My layout is based in original PICS', and so, it can't manage 3.3v.

Anyway, first you should confirm that your ICD works with 5V devices to discard other problems...

 

[elec_gu]

Hello again
The ICD2 clone works fine with pic18Fs (5V). It should work with 3.3V pics but it doesn't.
It has 74HC/HCT125 3-state buffer/line driver and I'm interfacing it right.
With a scope, I can see activity on DAT and CLK lines, but I always get the same:
Invalid target device id (expected=0x445, read=0x0)
I'm trying to program a PIC24FJ32GA002.
The PIC is Ok. I can program it with another programmer (old paralel port EPIC programmer!).

Has anybody any experience with ICD2 clones and those PIC24FJ32 PICS?.

thanks

 

[JamesQ]

Hello!

I have build a ICD2 Clone PICs (16F877A/18F4550). Im wondering, could i programm PIC18F45J10 useing one of the adapters for 5V->3.3V posted here? This is one exotic PIC. Im a noobie in microelectronics and i beg of your assistance.


Thank You very much.


HND-Have a nice day

 

[alunaro]

Questions about PICS ICD2 (rev B):

how much current can supply to target board ?
which is the output impedance of programmer (PGC/PGD lines) ?

Thanks

 

[ad_tech]

Hello again
The ICD2 clone works fine with pic18Fs (5V). It should work with 3.3V pics but it doesn't.
It has 74HC/HCT125 3-state buffer/line driver and I'm interfacing it right.
With a scope, I can see activity on DAT and CLK lines, but I always get the same:
Invalid target device id (expected=0x445, read=0x0)
I'm trying to program a PIC24FJ32GA002.
The PIC is Ok. I can program it with another programmer (old paralel port EPIC programmer!).

Has anybody any experience with ICD2 clones and those PIC24FJ32 PICS?.

thanks

To : elec_gu
Ref: your post of 19 Aug 2007 11:26

Have you or anyone else been able to measure accurately the clock and data rate going in and out of the PGC and PGD lines?.

You mentioned 74HC and 74HCT buffer types in your ICD2.
These become very slow as VDD drops. At 2V they are about 6 times slower than at 5 V.
Unfortunately data sheets don't show any values for 3.3 V.

If you have the possibility, I would recommend the 74AHC and 74AHCT types.
Your problem might be related with, rise and fall times and/or propagation delays.

A side note for users of ICD2 without buffers.
If you take a look at schematics of the PICKIT 2 programmer, you will see a simple and neat trick built with and around Q2, Q3 and Q5 to accommodate lower voltage devices.
If you like to do some experimenting, here's your chance.

Cheers
Augusto

 

[elec_gu]

To ad_tech:
First of all. Thank you for your answer.
I'm going to scope data and clock lines in order to measure timing. I'll do some comparison 5V vs 3.3v.

Tanks again for your answer. For me this is a sad history. First, I tried to do a USB ICD2 by myself following this page, but it was over my capabilities (double side board etc). Then I bought one by eBay. The seller ad stated it was 3.3v capable, but as far as I can say, it isn't. My following step should be to buy Microchip original one. As you can see, a long, stupid and expensive way of doing things

 

[potyo]

I have tested my icd2 with 16LF876 running at 1.6V :!: It works :arrow: 74HC is enough fast.

 

[ad_tech]

To ad_tech:
First of all. Thank you for your answer.
I'm going to scope data and clock lines in order to measure timing. I'll do some comparison 5V vs 3.3v.

Tanks again for your answer. For me this is a sad history. First, I tried to do a USB ICD2 by myself following this page, but it was over my capabilities (double side board etc). Then I bought one by eBay. The seller ad stated it was 3.3v capable, but as far as I can say, it isn't. My following step should be to buy Microchip original one. As you can see, a long, stupid and expensive way of doing things

To : elec_gu
Your story is troubling me.
I ordered some PIC24F and PIC24H a couple of days back.
I guess I may run into problems as you did.

This is just a dumb question. Are you connecting AVDD and AVSS as described in page 46 footnotes 1 and 2 of the PIC24F programming specifications (DS39768B)?

Is there any one out there who has worked with PIC24F/H and ICD2 clones successfully ?

I just made a side by side comparison of the programming timing requirements for PIC18F2xx and PIC24Fx and the results are very interesting to say the least.

To be quick about it, I will only mention 3 parameters of the PGC line.
Clock low, Clock high and Clock period

PIC 18F2x @ 2V 400 ns 400 ns 1000 nS
PIC 18F2x @ 5V 40 ns 40 ns 100 ns
PIC 24Fxx @ 3.3V 40 ns 40 ns 100 ns

This means that the ICD2 OS for PIC18F2x needs to adjust it's timings according to target VDD.
As you can see, clock timing for PIC18 @ 5V and PIC24F @3.3V is the same, but while programming PIC24F, the transmitting buffer is being supplied @ 3.3V which makes it a slower device while the timing requirements remain the same.

I'm guessing that, due to the larger memory of the 24F chips, MICROCHIP has probably ' squeezed ' as much as possible the programming timings to speed up matters.
This may also account for your problems with 24F and not with other devices.

To potyo:
You are right about programming PIC16LFx at low voltage. It can be done.
But the fact is that both buffers and PIC16LFx become slower at low voltages, and ICD2 firmware takes that into account when generating clock and data signals.
The problem is that PIC24 is programmed at a fixed voltage,(according to datasheet) so there is no need to ' adjust timings '.
At 3.3V 74HC devices might just be a tiny bit too slow.

Is there any proud owner of an original ICD2 on the house that could inform us about what type of buffers MICROCHIP ICD2 uses ?

A final note before I go:
As you can all see I joined this forum recently.
It took me about a week to read (several times ) all the messages posted here and one thing became immediately obvious to me.
Less than half a dozen guys really gave their best to put this thing to work.
I imagine they have invested several hundred hours on this with no gain on sight, just that nice feeling of self accomplishment.
To them I would like to leave here my public and deepest appreciation and a ' warm handshake '

Augusto Duro

 

[potyo]

To : ad_tech
On the other side, ICD2's soul is 16F877, which is 5MIPS controller. Theoretically it can produce signals on it's pins at 2.5MHz. In practic, frequency is much smaller, periode is surely much higher than 400ns.

74HC's max. propagation delay with 150pF load at 2V is 130ns, at 4.5V is 26ns, and at 6V is 22ns. At 3.3V it should be near 80ns, it is much lower than half of the 400ns.

I think, the problem is not with the level translators...


To : elec_gu
Can you test your ICD2 with an 18F running at lower voltage?

 

[newbyte]

I have tested my circuit in debug mode (tested with 16f877a target)

It works perfectly with MPLAB 7.6, debugging without problems.

I attach the source that i wrote (it is not nice, only for testing purporses). It has
notes about ICD2 debug mode and how to set it. Anyway, you can read the code

I have tested my circuit in debug mode (tested with 16f877a target)
i have this problem: ICD0083: Debug: Unable to enter debug mode
can you help me?