Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Project to replace CY7C64613 in the ICD2

Status
Not open for further replies.
microchip programming executive reprogram

Silvio,

the BL cannot be upgraded thing was a little trick. Actually MPLAB is set to check the BL's version against 0xFFFF, and if 0xFFFF (it's only a word) is lower than it will try to upgrade the bootloader. So it wont ever get here, because larger number than 0xFFFF cannot be set on a word. So I patched it to skip this test and try to do it, but anyway it's a BUILT IN function in MPLAB! It CAN update the boot image too. I just patched the version check out.
But think: it's not accidentaly set to 0xFFFF, they may not want to use this function yet.
According to the OS.bin file, if the product version is 0x0010 than it's downloaded all the time. Maybe 0x0010 is the BL's version only, and set to lower when OS will run in it! The OS.bin's version is also checked against 0xFFFF. If it's equals to 0xFFFF it's starts the checking for the BOOT.bin file as I mentoined above.

I'll check how it handles the active check when it complains about "it cannot be upgraded while active".

Another strange thing is if the original bootloader handles the decryption of the OS.bin image, than it will be a nice thing to clone... Anyway there is no processing on the .bin files in the software as I saw.

the DeviceIOControl command returns 0x57: The parameter is incorrect. (ERROR_INVALID_PARAMETER)

If we get the OS.bin downloaded than we can read it back with another icd2 and see how it works.

Albert,

they wont change the 877 firmware. They have a lot of hexs supplied with MPLAB should work with both versions. They may do minor changes, but thats all.
Sorry I misunderstood that DPOT thing.
The question "Why they supplied the boot image?" I asked was for the 4550_boot.bin file.
 

lothar stolz vpp

Hi guys !

Bad news. I could not install the USB monitor in my PC with Windows98SE, because it doesn´t accept to be installed. I think it (if installed) wouldn´t make any damage to my ICD2, but i could not test it.

About the Vpp control, I think that there is only the high voltage generator for Vpp and there is another way to control this voltage. I don´t know if the DG411 has this role, and there is a power mosfet also in the circuit.

I don´t think my clone is the new ICD2 from Microchip. I suppose the local manufacturer only made a clone using more available parts and making some changes in the firmware to adequate the new parts. Sorry I cannot make any attempt to read the 18F4550 contents.

Added after 15 minutes:

One more thing:

I tried to build the PICKIT2 programmer (onlu the basic part: the PIC, crystal and some connections) some weeks ago. It has the schematic and "all" the software available for download in the Microchip pages. I bought some 18F2550 and programmed with the firmware provided. I installed the programmer software and connected the hardware to the USB port. The PC recognized it once but the software did not. I think that there is something missing in the package, that blocks the programmer to communicate with the software. Could be the same case be happening with the hex files provided for the ICD2 ? Or in other words: Microchip does´t provide the complete code for the ICD2.
 

target vdd too high mplab icd2

Please
Can somebody export to .txt the USB log files captured by HDD monitor?
I cannot install this soft at my home. Otherwise Ill have to wait until next week to read them on my PC at work. I am now studying the protocol between the CY and the 877 OS.
If they are too big. A connect log, and a program log would be nice.
Thanks
 

dxp rj11 footprint

rkodaira said:
Hi guys !
Bad news. I could not install the USB monitor in my PC with Windows98SE, because it doesn´t accept to be installed. I think it (if installed) wouldn´t make any damage to my ICD2, but i could not test it.

may be you can try this one : they say it works under w98...
https://www.perisoft.net/bushound/

zedman needs a log of a real 4550... my cypress clone doesnt give all he needs...
 

potyo2 wikipedia

It can be exported from USBMon to HTML format, but I have only serial ICD2.
 

sure electronics icd2 pic32

Hi group,

Zedman drew my attention to this thread. I find it very interesting.

Last winter my hobby project was to build an ICD clone on a 2455/2550. I used the CDC firmware for RS232 emulation to connect to MPLAB. I disassambled the 877 firmware and made it more readable with a VB program. As far as I can tell the protocol CY<->877 and the protocol RS232<->877 are the same. There are no USB specific things in the 877 firmware.

I'll try to explain what I learned of the protocol.

MPLAB starts a connection by sending a 'Z'. ICD should reply with some kind of version nr in binary: 0x01,0x01,0x03.

Now MPLAB sends a
'V' if it wants to connect to the bootloader, ICD should reply with a 'v'
'U' if it wants to connect to the OS, ICD should reply 'u'

Next is the version of the ICD hardware, this has to be compatible with the old ICD1, so its different from all other commands: MPLAB send '$7F00\r', ICD replies '02' for ICD2

From here on all commands are send in packets in the form: '<', packet len, command, [params], checksum, '>'
all items are sent in hex, packet length is including the <>. An example: '<0801C9>', len=8, cmd=1 (GETFIRMWAREVERSION), no params, checksum=0xC9

Reply's to commands are in the same form, except packed in []. Reply to the above example would be: '[0E0102630102]', len=14, cmd=1 (GETFIRMWAREVERSION), param 2.99.1, checksum=0x02.

Large chunks of data are sent in {} packets : {data [,data..], checksum}. For example the write program command:
MPLAB: <184300005DC000000120FF>, len 24, cmd=0x43 (WRITEPROGRAM), program size= 0x05DC, start address=0x0120, checksum = 0xFF
ICD: [0843CF], len 8, cmd 0x43, checksum 0xCF
MPLAB: {FF3FFF3F.....3C} , data data data.., checksum-0x3C
ICD: [0843CF], ack cmd 0x43 again



I used the information from this thread to connect my existing program with the real ICD USB Driver. I got so far that I receive the GETFIRMWAREVERSION command, but my response seems not to be understood. It sends the same command again and then hangs (?) .
 

a08s icd2

It can be exported from USBMon to HTML format, but I have only serial ICD2.
Zedman may be you can open the log files that had been posted here and export them to html. No need to have the USB ICD2.

Brem,
Great. I was just at the routines that handle connection with the ICD once the OS is loaded. Thanks.
 

jaomiki

Hey Brem!

nice to see you here!
Thanks for the infos on the protocol.

I used the information from this thread to connect my existing program with the real ICD USB Driver. I got so far that I receive the GETFIRMWAREVERSION command, but my response seems not to be understood. It sends the same command again and then hangs (?) .


would you please explain this a bit more? What's that mean you response is not understood? You got an usb packet starting with 0x01, replied it succesfully and just the content was wrong?

Please explain this, because as you can see from the thread Iam stuck with the replying. :cry:

-------------------

Iam now trying an alternate way to suck with the replying thing, I wrote a small program in Delphi to test if the reply works, getting the same results yet but it's faster than switching the programmer in mplab while using it too.

here is the proc (values got from disassembled/debugged MPLBCOMM.dll):
Code:
procedure TForm1.Button1Click(Sender: TObject);
var hnd: cardinal;
    InBuffer: array[0..3] of byte;
    OutBuffer: array[0..17] of byte;
    bytesReturned: cardinal;
    a: integer;
begin
  hnd:=CreateFile('\\.\i3kmc-0', $C0000000, 2, 0, 3, 0, 0);

  if hnd <> INVALID_HANDLE_VALUE then
  begin
    // get usb descriptor
    for a:=0 to 3 do InBuffer[a]:=0; for a:=0 to 17 do OutBuffer[a]:=0; bytesReturned:=0;
    if (DeviceIoControl(hnd, $0A4122404, @InBuffer, 4, @OutBuffer, $12, bytesReturned, nil)) then
    begin
      Memo1.Lines.Add('1 OK');
    end;

    // write command
    for a:=0 to 3 do InBuffer[a]:=0; for a:=0 to 17 do OutBuffer[a]:=0; bytesReturned:=0;
    OutBuffer[0]:=3;
    if (DeviceIoControl(hnd, $0A4122451, @InBuffer, 4, @OutBuffer, $12, bytesReturned, nil)) then
    begin
      Memo1.Lines.Add('2 OK');
    end;

    // get status
    for a:=0 to 3 do InBuffer[a]:=0; for a:=0 to 17 do OutBuffer[a]:=0; bytesReturned:=0;
    InBuffer[0]:=7;
    if (DeviceIoControl(hnd, $0A412244E, @InBuffer, 4, @OutBuffer, 0, bytesReturned, nil)) then
    begin
      Memo1.Lines.Add('3 OK');
    end;
    Memo1.Lines.Add('- done.');
  end;
end;

the 3rd DeviceIOControl returns failed.

I can't even remeber how my wife look like... :|
 

icd2 choke

Hi Zedman,

Besides some recognizable data like the 'Z', the 'U' and <0801C9>, I receive packets I don't understand. They are all 18 bytes long, 1st char is 0x00,0x01 or 0x02, 2nd char seems to be some kind of seq.nr, 3rd byte a length.

First packet received is:
HOST->DEV: 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I reply with 8 x 0
DEV->HOST: 00 00 00 00 00 00 00 00 00
Second packet received is:
HOST->DEV: 01 C2 01 00 00 00 00 00 00 00 C9 00 00 00 00 00 00 00
Here the first byte 0x01 seems to mean "data incoming", 3rd bytes undicates length. I dont send reply on this packet.
Next rcvd is a singe 'Z', I reply with the hardware version
HOST->DEV: 5A
DEV->HOST: 01 01 03
Next again a packet starting with 0x02, same reply
HOST->DEV: 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DEV->HOST: 00 00 00 00 00 00 00 00 00
then a "data incoming" packet folowed by a 'U', connect to OS
HOST-DEV: 01 C2 01 00 00 00 00 00 00 00 C9 00 00 00 00 00 00 00
HOST-DEV: 55
Now MPLAB seems to want 8 bytes so I send a 'u' with 7 zeros
DEV->HOST: 75 00 00 00 00 00 00 00

Now comes the tricky part. A packet starting with 0x02 means MPLAB wants data on EP2.
HOST-DEV: 02 C3 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DEV-HOST (on EP2!!): 75
DEV-HOST (on EP1): 00 00 00 00 00 00 00 00

And here I get stuck at the moment. MPLAB sends a <0801C9> but my response is ignored. I think from here on the ICD should send all data over EP2.
 

74lvc8t245 datasheet

Brem,

Iam a lamer. PLEASE TELL ME how do you reply?
How the hell does it work for you?
What am I missing?
If I set up the shared ram with 0s set the Cnt to 8 and set UOWN bit to SIE, MPLAB wont send me ANY more data, and UOWN never get cleared!!
But from this I see u managed it to work!!!

HELP ME PLEASE!

Code:
HOST->DEV: 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
I reply with 8 x 0 
DEV->HOST: 00 00 00 00 00 00 00 00 00
 

18f4550 vid_0000&pid_0000

Hi!

I'm playing with it right now, and I'm a lot further, MPLAB seems to be happy now with my ICD:
Code:
MPLAB ICD 2 Ready
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
ICDWarn0020: Invalid target device id (expected=0x93, read=0x58)
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
My test board doesn't have ICD hardware so i get a funny device id.


This is what I think I understand from the USB part of the protocol.

- control packets and data for ICD are both sent over EP1.
- each control packet needs to ACKed over EP1, just send 8 zero's over EP1.
- if data for ICD is going to be sent over EP1, it will be announced by a control packet. This is how you can keep the ICD data apart from control packets.
- control packets are 18 bytes long, but only 4 bytes seem ever to contain data.
- if first byte = 0x01 it means "data incoming on EP1", 3rd byte contains length. Next pkt rcvd on EP1 is data for ICD.
- if first byte = 0x00 it means "request data over EP2", 3rd byte length. ICD data should now be sent over EP2, followed by an ACK (8 zero's) over EP1.
- if first byte = 0x02, I just ACK it. Dont know what it means, maybe some status request or so.
- I didn't see any other control packets.


, MPLAB wont send me ANY more data,
Isn't it waiting for data on EP2? You should be able to see that on a USB monitor?
 

icd2w2k.inf 2000

Brem please can you send me your sources? (my mail is in my profile) I know Iam asking too much, but iam going insane becauseof this, I tried to send over EP2 too, but nothing happens.
Iam hungry for analysing the protocol as you do but sucking with this silly problem...

thanks in advance!

Added after 18 minutes:

I am @work now i'll be home in 5 hours and will work on it.
 

icd2 clone nick7

hmm, thats strange. I can see my profile and it has my mail. But I GOT it. and don't worry I hate to deal with multiple c files too.
THANKS!

Added after 15 minutes:

at the first sight I initialize only EP1 for IN/OUT and EP2 for OUT (only), you initialize 7 IN/OUT EPs. 8)

-------

Albert here are the logs.
 

tps6734 problems

More info I checked inside the MPLAB-IDE and in the Windows system information:

Mplab ICD2 Version 07.20.09.00
Firmware: ICD2
Firmware Type: 18F_EGG
Firmware Version: 01.02.05.00
Bootloader Version: 01.01.01.00


Drivers: ICD2w98.Sys and MCDRV48F.DLL

I did the USB dumping when the MPLAP communicates with the ICD2 clone. Here is the dump:

===================================================
Bus Hound 5.04 capture on Windows 98 SE. Complements of www.perisoft.net

Device - Device ID (followed by the endpoint for USB devices)
(9) Microchip MPLAB ICD 2 Firmware Client
Phase - Phase Type
IN Data in transfer
OUT Data out transfer
Data - Hex dump of the data transferred
Descr - Description of the phase
Cmd... - Position in the captured data


Device Phase Data Description Cmd.Phase.Ofs(rep)
------ ----- ------------------------ ---------------- ------------------
9.1 OUT 02 c1 00 00 00 00 00 00 ........ 1.1.0
9.1 IN 02 00 00 00 00 00 00 00 ........ 2.1.0
9.1 OUT 01 c2 01 00 00 00 00 00 ........ 3.1.0
9.1 OUT 5a Z 4.1.0
9.1 IN 01 00 00 00 00 00 00 00 ........ 5.1.0
9.1 OUT 00 c3 04 00 00 00 00 00 ........ 6.1.0
9.2 IN 01 01 01 03 .... 7.1.0
9.1 IN 00 00 00 00 00 00 00 00 ........ 8.1.0
9.1 OUT 02 c4 00 00 00 00 00 00 ........ 9.1.0
9.1 IN 02 00 00 00 00 00 00 00 ........ 10.1.0
9.1 OUT 01 c5 01 00 00 00 00 00 ........ 11.1.0
9.1 OUT 55 U 12.1.0
9.1 IN 01 00 00 00 00 00 00 00 ........ 13.1.0
9.1 OUT 00 c6 01 00 00 00 00 00 ........ 14.1.0
9.2 IN 75 u 15.1.0
9.1 IN 00 00 00 00 00 00 00 00 ........ 16.1.0
9.1 OUT 01 c7 08 00 00 00 00 00 ........ 17.1.0
9.1 OUT 3c 30 38 30 31 43 39 3e <0801C9> 18.1.0
9.1 IN 01 00 00 00 00 00 00 00 ........ 19.1.0
9.1 OUT 00 c8 0e 00 00 00 00 00 ........ 20.1.0
9.2 IN 5b 30 45 30 31 30 31 30 [0E01010 21.1.0
9.1 IN 00 00 00 00 00 00 00 00 ........ 22.1.0
9.1 OUT 01 c9 08 00 00 00 00 00 ........ 23.1.0
9.1 OUT 3c 30 38 30 37 43 46 3e <0807CF> 24.1.0
9.1 IN 01 00 00 00 00 00 00 00 ........ 25.1.0
9.1 OUT 00 ca 0a 00 00 00 00 00 ........ 26.1.0
9.2 IN 5b 30 41 30 37 30 35 33 [0A07053 27.1.0
9.1 IN 00 00 00 00 00 00 00 00 ........ 28.1.0
9.1 OUT 01 cb 0a 00 00 00 00 00 ........ 29.1.0
9.1 OUT 3c 30 41 32 41 38 42 35 <0A2A8B5 30.1.0
9.1 IN 01 00 00 00 00 00 00 00 ........ 31.1.0
9.1 OUT 00 cc 08 00 00 00 00 00 ........ 32.1.0
 

target halted mplab

Zedman, the logs in logs.zip contain no data. Just time stamp and number of bytes transfered. Anyway I have something to start with the logs and info posted by Brem.

Today I got my 4550. Going to build the board asap to join the fun.
 

firmware load cy7c64613

Awesome! I've been looking for a true USB ICD2 for awhile now and this looks to be very close to a working prototype! :D

I don't know much about debugging USB comm but if you guys get the software figured out I could help with the layout and remaining analog circuitry. We use real ICD2's at work and we blow them up every now and again so it'd be nice to build some cheap ones that we don't have to worry about. Let me know if there's anything I can do to help out :twisted:
 

usb programmer use 74ls125

Sorry Albert, my fault!

sending html versions.

----------------------------------

Brem,

do you have any idea if I have to transfer more than 64 bytes why it hangs after 4 or 5 transmissions? PIC just waits for UOWN to get cleared. I debugged the PC side, it wants > 10000 bytes in 64 byte blocks continously, but usually after the 4th packet sent in the next ReadData call hangs.

doing this in a cycle>
Code:
  for (a=0; a<64; a++) { icd2_data_tx[a]=0xFF; }
  ICD2_DATA_BD_IN.Cnt = 64;
  mUSBBufferReady(ICD2_DATA_BD_IN);
  LED=1; while(mDataTXBusy() == 1); LED=0;
 

pic icd clone india

Yes indeed, should be something like: LED=0; while(...) USBTasks(); LED=1;

...if I have to transfer more than 64 bytes why it hangs ...
This suggests you are almost there! As far as I know you only need to send >64 bytes when the ICD is reading or verifying data/program memory on the target device.
Thanks for the logs, seems like sending 8 zero's is not the correct way to ACK a control packet.
 

rj11 icd2 target device pinout

Now Iam here:

Code:
ICDWarn0059: About to re-program ICD2 USB Boot firmware code. Please do NOT disconnect the ICD2 or interrupt this operation!

It stuck with receiving the code to burn, it should come out from EP2 OUT, but it wont. The PC hangs in the MPLABWriteData call. Seems that the PIC cannot receive or waiting on wrong EP (now trying the others).

Added after 2 hours 20 minutes:

Ok guys here is the thing! 8)

After 2 weeks of debug:

The 2 bins CAN be burned into a 4550. And it (will) work. Actually now Iam tired, burned them in but it fails USB enumeration yet, but the code is looks OK in MPLAB and can be debugged. I think it looks for some hw thing before it let itself run further.

There is no config data in the hex file, I used the config I used with my USB project cloned from the Mchip Boot fw or the CDC example. Actually it's not exactly defined. Maybe Rkodaira would help us out with this issue. (If his 4550 is protected the config can be read? It's too late here to check the ds...)
 

unable to communicate with icd

Hi Zedman !

Great progress ! About your request: I am still in trouble to read the 4550 contents because i don´t have another programmer able to read it. Anyway, the crystal is 20MHz but i was reading the datasheet and for USB operation, the PIC must run at 48MHz. So I think there is a configuration to divide the 20MHz signal and rebuild to 48 MHz clock (PLL ??) to PIC main clock. I don´t think the configuration addresses are locked but for now i can´t read it.

Added after 3 minutes:

One curiosity: where do you come from or where are all of you located ? Just to know because the local time (fuses) are different and there are some delays in reading and answering the messages. I am located in Sao Paulo - Brasil (GMT - 3)
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top