[SOLVED] Project to replace CY7C64613 in the ICD2

[Kripton2035]

24fj start port boot

My friends i didn't succeed in programming ICD2_4550_BOOT_0180.BIN into 4550. I'v
tried to open bin file with winpic 800 software but it failed. I tryed to open it with option "all files" in "file types" because there is no direct support for bin files. ICprog have that support (to open bin files) but can't program 4550. In fact there is no 4550 in device list. What should i do next? Any suggestions? I'm just a beginner but I have good will to help.
Sorry about my bad english.

rename the .BIN to .HEX and winpic will open it !
sometimes a lot of files are .BIN in reality are intel .hex !
to be sure, open the file with notepad, if it contains lines beginning with ":" then rename to .hex and open it with winpic.. if it's garbage, then a bin2hex must be used to open it.

 

[narccizzo]

osc1 - 6 mhz crystal, my guess

These are the two files bin converted into hex, i've opened the bin files with the
ic-prog software then i save the files in hex format, if you take a look to these files you can see a readable string "Microchip Tecnology ICD2 USB Device icd2 usb" in the address 0x0ee7 for the boot.hex file and the same string in the 0x0b8e for the
os.hex file, i dont have a disassembler to explore in more detail this files but something tells me that these two files are all that we need.

BR
Narccizzo

 

[Jay.slovak]

potyo 2007.06.21 icd2

These are the two files bin converted into hex, i've opened the bin files with the
ic-prog software then i save the files in hex format, if you take a look to these files you can see a readable string "Microchip Tecnology ICD2 USB Device icd2 usb" in the address 0x0ee7 for the boot.hex file and the same string in the 0x0b8e for the
os.hex file, i dont have a disassembler to explore in more detail this files but something tells me that these two files are all that we need.

BR
Narccizzo

Are you sure you have converted the files correctly? If I import them into MPLAB, the code doesn't make sense, all it does is just going through the Program memory and doing NOPs. Nothing usefull is happening in both Boot and OS HEXs. Even config bits are different in both files!

 

[Zedman]

pic18f4550 picpgm lvisp

albert,

the kernel driver(s) expect, the cypress will connect on a different vid/pid when firt connected, and after the loader sys downloads it's fw it will reconnect as another vid/pid so the other sys talks to it. We have to implement only the second one.
Iam @work so I can't do anything here expect hard thinkin' :roll:...

 

[silvio]

lvp configuration bit pic18f4550 picpgm

Hi Zedman,

Regarding CY hex file it's not only a matter of good disassembler which knows the cypress chip, but reading of 436 pages EZ-USB FX TechRefManual it's a must to understand what's under cover.
And I don't believe you've time for this. Nevertheless, if you're not familiar with 8051 opcodes, parsing the code will take some time. ( I know you're familar with PIC ones)
I can replace all the occurance of MOV DPTR,#LXXXX with appropiate values from CY7C64613 registers 0x7800-0x7FFF but you'll definitely end up turning the pages of TechRefManual looking for definitions.
Besides that it would some how difficult to assign bits names which are set or clear in the program as long as they are not mapped in SFR space (which ends in 0 or 8 ).
It's easy to replace MOV DPTR, #L7FB4 with MOV DPTR, #EP0CS but it's difficult to say SETB HSNAK due to the above reasons.

Let's take the example bits HSNAK and EP0STALL which are affected in the bellow code at 0x03E2.

L03E2:	LCALL L0FBE
	JNC L03EE
	MOV DPTR,#L7FB4
	MOVX A,@DPTR
	ORL A,#01h      ;some kind of SETB EP0STALL
	MOVX @DPTR,A
L03EE:	MOV DPTR,#L7FB4
	MOVX A,@DPTR
	ORL A,#02h      ;some kind of SETB HSNAK
	MOVX @DPTR,A
	RET 

L0FBE:	SETB C
	RET

Take for example (CP_1.asm) the code lines starting with offset 0x0100 (a subroutine called from 0x05FA ), the first code line used immediatelly bellow vector interrupt table
At RAM 0x7FE9 you can find 2nd byte of the 8 bytes USB SETUP packet data (see page 215 table9-1), meaning bRequest field (see table 9-2).

L0100:	MOV DPTR,#L7FE9
	MOVX A,@DPTR
	JNZ L0109
	LJMP L029B      ;if bRequest = GetStatus jump to 0x029B
L0109:	DEC A
	JNZ L010F
	LJMP L0317      ;if bRequest = Clear Feature, jump to 0x0317
L010F:	ADD A,#0FEh
	JNZ L0116
	LJMP L038E      ;if bRequest = Set Feature, jump to 0x038E
L0116:	ADD A,#0FBh
	JNZ L011D
	LJMP L0295      ;if bRequest = Get Configuration, jump to 0x0295
L011D:	DEC A
	JNZ L0123
	LJMP L028F      ;if bRequest = Set Configuration, jump to 0x028F
L0123:	DEC A
	JNZ L0129
	LJMP L0283      ;if bRequest = Get Interface, jump to 0x0283
L0129:	DEC A
	JNZ L012F
	LJMP L0289      ;if bRequest = Set Interface, jump to 0x0289
L012F:	ADD A,#05h
	JZ L0136
	LJMP L03E2      ;if bRequest = none of the above, then set bits HSNAK
                        ;and EP0STALL of EP0CS control  & status register and
                        ;then RET at 0x05FD
                        ; 
L0136:	LCALL L0F7A     ;if bRequest = Get Descriptor, LCALL 0x0F7A where
	JC L013E        ;carry bit is set by default, so jump to 0x013E
	LJMP L03EE      ;if at 0x0F7A carry would be 0 by default, set bit HSNAK
                        ;of EP0CS control & status register and RET at 0x05FD
                        ;
L013E:	MOV DPTR,#L7FEB ;here because bRequest was a Get Descriptor
	MOVX A,@DPTR    ;thus, check the WValueH field of USB SETUP packet
	ADD A,#0FEh
	JZ L015F        ;if wValueH was 0x02 jump to 0x015F
	DEC A
	JZ L0190        ;if wValueH was 0x03 jump to 0x0190
	ADD A,#02h
	JZ L0150        ;if wValueH was 0x01 jump to 0x0150
	LJMP L0279      ;if wValueh is different of either 0x01 or 0x02 or 0x03 then set
                        ;bits HSNAK and EP0STALL of EP0CS register and RET at 0x05FD
                        ;
L0150:	MOV A,0Ch       ;here because wValueH was 0x01, so load SUDPTR global USB register
	MOV DPTR,#L7FD4 ;with value 0x0C0D, then set bit HSNAK of EP0CS and RET at 0x05FD
	MOVX @DPTR,A
	MOV A,0Dh
	MOV DPTR,#L7FD5
	MOVX @DPTR,A
	LJMP L03EE
L015F:	MOV DPTR,#L7FEA ;look now at wValueL field of USB SETUP packet
;
;
;
;
;and so on...................

Or this lookup table at offset 0x0622 which match the Kripton2035 port2: Microchip MPLAB ICD2 Fw client

Table 5-9. USB Default Device Descriptor

RAM  Value  Offset Field        Description

0622 0x12  0 bLength            Length of this Descriptor = 18 bytes
0623 0x01  1 bDescriptorType    Descriptor Type = Device
0624 0x00  2 bcdUSB (L)         USB Specification Version 1.10 (L)
0625 0x01  3 bcdUSB (H)         USB Specification Version 1.10 (H)
0626 0xFF  4 bDeviceClass       Device Class (FF is Vendor-Specific)
0627 0xFF  5 bDeviceSubClass    Device Sub-Class (FF is Vendor-Specific)
0628 0xFF  6 bDeviceProtocol    Device Protocol (FF is Vendor-Specific)
0629 0x40  7 bMaxPacketSize0    Maximum Packet Size for EP0 = 64 bytes
062A 0xD8  8 idVendor (L)       Vendor ID (L) Microchip Technology = 04D8H
062B 0x04  9 idVendor (H)       Vendor ID (H)
062C 0x01 10 idProduct (L)      Product ID (L) ICD2 = 8001H
062D 0x80 11 idProduct (H)      Product ID (H)
062E 0x03 12 bcdDevice (L)      Device Release Number (BCD,L)
062F 0x00 13 bcdDevice (H)      Device Release Number (BCD,H)
0630 0x00 14 iManufacturer      Manufacturer Index String = None
0631 0x00 15 iProduct           Product Index String = None
0632 0x00 16 iSerialNumber      Serial Number Index String = None
0633 0x01 17 bNumConfigurations Number of Configurations in this Interface = 1

Table 5-10. USB Default Configuration Descriptor

RAM  Value  Offset Field        Description

0634 0x09  0 bLength            Length of this Descriptor = 9 bytes
0635 0x02  1 bDescriptorType    Descriptor Type = Configuration
0636 0x74  2 wTotalLength (L)   Total Length (L) Including Interface and Endpoint Descriptors = 116
0637 0x00  3 wTotalLength (H)   Total Length (H)
0638 0x01  4 bNumInterfaces     Number of Interfaces in this Configuration
0639 0x01  5 bConfigurationValue Configuration Value Used by Set_Configuration Request to Select this Configuration
063A 0x00  6 iConfiguration     Index of String Describing this Configuration = None
063B 0x80  7 bmAttributes       Attributes - Bus-Powered, No Wakeup
063C 0x4B  8 MaxPower           Maximum Power - 150 mA

Table 5-11. USB Default Interface 0, Alternate Setting 0 Descriptor

RAM  Value  Offset Field        Description

063D 0x09  0 bLength            Length of the Interface Descriptor
063E 0x04  1 bDescriptorType    Descriptor Type = Interface
063F 0x00  2 bInterfaceNumber   Zero-based Index of this Interface = 0
0640 0x00  3 bAlternateSetting  Alternate Setting Value = 0
0641 0x0E  4 bNumEndpoints      Number of Endpoints in this Interface (Not Counting EPO) = 14
0642 0xFF  5 bInterfaceClass    Interface Class = Vendor Specific
0643 0xFF  6 bInterfaceSubClass Interface Sub-class = Vendor Specific
0644 0xFF  7 bInterfaceProtocol Interface Protocol = Vendor Specific
0645 0x00  8 iInterface         Index to String Descriptor for this Interface = None

Table 5-14. Default Interface 0, Alternate Setting 1, Bulk Endpoint Descriptors

RAM  Value  Offset Field        Description

0646 0x07  0 bLength            Length of this Endpoint Descriptor
0647 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0648 0x01  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT1
0649 0x02  3 bmAttributes       XFR Type = BULK
064A 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
064B 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
064C 0x01  6 bInterval          Polling Interval in Milliseconds

064D 0x07  0 bLength            Length of this Endpoint Descriptor
064E 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
064F 0x02  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT2
0650 0x02  3 bmAttributes       XFR Type = BULK
0651 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0652 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0653 0x01  6 bInterval          Polling Interval in Milliseconds

0654 0x07  0 bLength            Length of this Endpoint Descriptor
0655 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0656 0x03  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT3
0657 0x02  3 bmAttributes       XFR Type = BULK
0658 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0659 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
065A 0x01  6 bInterval          Polling Interval in Milliseconds

065B 0x07  0 bLength            Length of this Endpoint Descriptor
065C 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
065D 0x04  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT4
065E 0x02  3 bmAttributes       XFR Type = BULK
065F 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0660 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0661 0x01  6 bInterval          Polling Interval in Milliseconds

0662 0x07  0 bLength            Length of this Endpoint Descriptor
0663 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0664 0x05  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT5
0665 0x02  3 bmAttributes       XFR Type = BULK
0666 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0667 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0668 0x01  6 bInterval          Polling Interval in Milliseconds

0669 0x07  0 bLength            Length of this Endpoint Descriptor
066A 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
066B 0x06  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT6
066C 0x02  3 bmAttributes       XFR Type = BULK
066D 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
066E 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
066F 0x01  6 bInterval          Polling Interval in Milliseconds

0670 0x07  0 bLength            Length of this Endpoint Descriptor
0671 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0672 0x07  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = OUT7
0673 0x02  3 bmAttributes       XFR Type = BULK
0674 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0675 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0676 0x01  6 bInterval          Polling Interval in Milliseconds

RAM  Value  Offset Field        Description

0677 0x07  0 bLength            Length of this Endpoint Descriptor
0678 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0679 0x81  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN1
067A 0x02  3 bmAttributes       XFR Type = BULK
067B 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
067C 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
067D 0x01  6 bInterval          Polling Interval in Milliseconds

067E 0x07  0 bLength            Length of this Endpoint Descriptor
067F 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0680 0x82  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN2
0681 0x02  3 bmAttributes       XFR Type = BULK
0682 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0683 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0684 0x01  6 bInterval          Polling Interval in Milliseconds

0685 0x07  0 bLength            Length of this Endpoint Descriptor
0686 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0687 0x83  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN3
0688 0x02  3 bmAttributes       XFR Type = BULK
0689 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
068A 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
068B 0x01  6 bInterval          Polling Interval in Milliseconds

068C 0x07  0 bLength            Length of this Endpoint Descriptor
068D 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
068E 0x84  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN4
068F 0x02  3 bmAttributes       XFR Type = BULK
0690 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0691 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0692 0x01  6 bInterval          Polling Interval in Milliseconds

0693 0x07  0 bLength            Length of this Endpoint Descriptor
0694 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
0695 0x85  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN5
0696 0x02  3 bmAttributes       XFR Type = BULK
0697 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
0698 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
0699 0x01  6 bInterval          Polling Interval in Milliseconds

069A 0x07  0 bLength            Length of this Endpoint Descriptor
069B 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
069C 0x86  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN6
069D 0x02  3 bmAttributes       XFR Type = BULK
069E 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
069F 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
06A0 0x01  6 bInterval          Polling Interval in Milliseconds

06A1 0x07  0 bLength            Length of this Endpoint Descriptor
06A2 0x05  1 bDescriptor        Type Descriptor Type = Endpoint
06A3 0x87  2 bEndpointAddress   Endpoint Direction (1 is in) and Address = IN7
06A4 0x02  3 bmAttributes       XFR Type = BULK
06A5 0x40  4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes
06A6 0x00  5 wMaxPacketSize (H) Maximum Packet Size - High
06A7 0x01  6 bInterval          Polling Interval in Milliseconds

which is then followed by unicode form of zero ended string
"Microchip Technology ICD2 USB Device"

However if you get stuck with 4550 bin, I can try to help by adding comments in the CY asm file.

 

[Zedman]

picpgm lvisp pic18f4550

Hi Silvio,

thanks for the infos, LONG time ago I had to parse a bin file coming from an eprom chip. I didn't even no the processor type nor the circuit. But I had to find how it deals with a memory card, and it's data.
I assumed it's a 8051 kind of chip and tried a lot of disassemblers, and ended up with a 80C542 (i cant remember which one was it exactly) I figured it out from the port numbers and how the code deals with individual port pins.
But it took 2 weeks day and night work :| for me, lot of reading/debugging/learning.
That's why i wanted an assembler what's capable to do the things you mentioned instead me...
Thanks again Silvio.

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

Iam starting to believe you all, according to bin files. I did a research in ICD2 dll and found out that it calls GETUSBDESCRIPTOR and checks numbers in the descriptor and if it matches newer version ICD2 than I signed in my 4550's descriptor than it does a send4550image call!
And also there are descriptors in the bin files identical to the one Kripton uploaded.
One thing I don't understand that is why did they supplied the boot image?
And why ICD2.dll tries to download this file? If I get home, i'll try to set my descriptors to match the one I found in the bin and will try MPLAB on it.

I think we are getting closer! 8)

Added after 46 minutes:

And there is a magic thing in the first btyes of the boot bin: MCHP (MiCrocHiP?)
I've searched for it, if it's later (after load) replaces these with real entry point GOTO or st, but in the ICD2.dll not.

Added after 3 hours 34 minutes:

Look at this:

I did what i said before, just set the version number to the newer it expects and MPLAB tries to send the OS! (Of course my fw is not a boot loader)

MPLAB ICD 2 Ready
Connecting to MPLAB ICD 2
ICD0289: Unable to re-program ICD2 USB OS firmware.
ICD0021: Unable to connect with MPLAB ICD 2
MPLAB ICD 2 Ready

Somehow the boot loader should work, i'll try to do something at night.

 

[narccizzo]

#fuses pic16f877a mplab 8.10

Hi JaySlovak
No, Im not sure, I only opened the bin and save it in hex format.

 

[Jay.slovak]

hex bin　convert　icd2_4550_boot_

Hi JaySlovak
No, Im not sure, I only opened the bin and save it in hex format.

Yep, it is wierd as the string is readable, just the code does nothing

 

[Zedman]

icd2 failed to enter debug mode after halt

Good news after 2 hours of debugging,

ICD2.dll does use BOTH of bin files. The OS file wants to be downloaded only to ICD2s with new product serial number.
BUT when you modify the version id in the filename of OS.bin to *_FFFF.bin than it starts to check the bootloader version look:

Connecting to MPLAB ICD 2
ICDWarn0062: The USB Boot firmware of the ICD2 is active and providing communications with the ICD2. This firmware is out-of-date and should be updated. It cannot be updated while active. However, you may continue to operate with the current boot firmware if you choose to do so. Do you want to continue?

If I press YES here than it tries to connect to ICD2 itself, and freezes (I have only the 4550 installed yet).
If I press NO than it seems it tries to update it but we NEED here a bootloader like this, so this message appears:

ICD0288: Unable to re-program ICD2 USB Boot firmware.
ICD0021: Unable to connect with MPLAB ICD 2
MPLAB ICD 2 Ready

Okay guys, think think think HOW can we use that bin to get a working bootloader into a 4550!!!

Added after 2 minutes:

I also compiled the sample bootloader with the correct VID / PID but got the same results as with my 4550.

Added after 16 minutes:

It can be, that we can't get the initial initial initial part of the bootloader which loads the first bootloader which loads the os...

Added after 5 minutes:

This is the time when rkodaira should dump his 4550 for the 0 level bootloader. (with a big hope that is not protected...)

Rkodaira WE NEED YOU

 

[albert22]

icd2 protocol list

I have been analyzing a printout that I have with me of the BL010101. and find some things.
It seems to accept 5 commands comming either from the PSP or the USART.
0x55 Execute code starting at 0x0010.
0x56 Load hex ( this one seems to have more subcommands)
0x5a sends the data 0x01 0x01 0x03 ( Version of the BL ???? )
Two other commands just turn on the Error and Busy Leds and hangs in an inffinite loop.

The following routines are related to what I called the "load hex" command:

In another routine the BL sends the following string 0x5b,"0810C9",0x5d
Other sends answers embeded into the following string 0x5b,"0A000",U,0x31,U,0x5d. (where U seems to be 0x31,0x34,0x36 and 0x37).

I didnt have much time to continue with the analysis. I neither saw the USB monitoring that have been posted because Im at a cyber. But I think this data should be packed into the USB communication

 

[Zedman]

icd2 protocol serial

albert,

I checked the serial comm versus the USB, USB uses a wrapper trough the serial thing.
It seems it uses EP1 for control port (it's OUT and IN) and EP2 as data port, only IN (icd->pc).

 

[albert22]

pic32 icd2 problem

Here are my advances with the BL
There were no such subcommands. The load hex command just takes the hex records and writes the data to the program memory 2 bytes at a time. It checks for different errors including the range of address. Ap. to avoid stepping into the BL program. This confirms that the BL is allways resident at the 877.
The [0A000",U,0x31,U]. (the 2nd U is the first U+1) is unlikely to be seen because it is an error report. Errors include: bad format, checksum, bad address range and EEPROM write error.
The routine waits for 16 characters starting with a 0x3c ('<') and ending with a 0x3e ('>'). this 16 characters header contain the address, length and checksum for the data to be written in ASCII.
If the header is correct Ap. the BL answers with "[0810C9]"
The data cames after a 0x7b
This format seems to be different from an intel hex format.

Zedman.
May be you recognized something like this in the RS232
Tomorrow I wil be at my home and able to install hdd to check the logs and see if I can be of any help.

 

[Zedman]

cy7c64613 driver vista

I am stuck with this USB thing. And I am sad.

I don't really know what to do next. I spent a lot of time debugging the icd2.dll.

The problem is: I can't send even one byte back to MPLAB.

I'll explain what I found till now, altough noone really interested in (just want to grab the finished thing). (Except: albert, Kripton, rkodaira, silvio and the guys in this thread)

So, MPLAB communicates with the ICD2 this way:

[MPLAB -> ICD2.dll -> MPLBCOMM.dll -> icd2w2k.sys -> ] --- [ICD2 device]

If you choose USB type connection it will ask the device descriptor from the ICD2 and checks for the product version word, if it's 0x0003 than it's a Cypress based ICD2, if it's 0x0010 than it's a 4550 based one. If 0x0010 found than it says what I've been posted before that the OS in the ICD2 must be upgraded. It's interesting that if the version (0100) in the filename of the OS.bin is modified to FFFF than it skips this step and checks the bootloader version. Here I had to patch ICD2.dll to get it try to check the BL.bin file's version too, it's hardcoded that even it's set to FFFF it wont try to upgrade, that's why I patched it (set hardcoded FFFF to lower) so now says what I mentoined too before: the bl version is too old but it cannot be upgraded while it's active.

Okay. I made a small prog from the sample bootloader, with the correct descriptors and trying to communicate with MPLAB in order to decrypt the protocol and to emulate the BL in the new 4550 ICD2.
ICD2 that Kripton uses, (cypress version) sets 7 OUT/IN Endpoints, but according to the logs it uses only EP1 for IN/OUT and EP2 for IN. (OUT means PC->Device)
It seems it sends the usb specific commands and data through EP1 out, and back on EP1 in, and sends the bytes readed from the ICD2's 877 through separate endpoint EP2 in.

When MPLAB tries to send th OS.bin to upgrade the fw os it issues a getUSBdescriptor call to the kernel driver, and sends out a 0x12 bytes long command using DeviceIOControl command. I debugged, it arrives succesfully to the 4550.
Than MPLAB issues a GetStatus call, and it seems from the call parameters that it expects 0x08 bytes of data back.
I set up my buffer with 8 bytes, and set the ownership to SIE. But it never sends that 8 byte back (it does not appear in USBMon). Just waits.
There can be many things.
Maybe I do st wrong with the setup of 4550, but I tried it with another progs and it works, can send bytes back.
I know the host must send and IN command to let the device send in what it wants.
But when I debugged MBLBCOMM, I saw that the DeviceIOControl command failed!
I tought that maybe some intelligence was built into the .sys file and it drops the packet because of it's wrong contents, but I think it SHOULD be a higher level task.
When I get home I'll check the Getlasterror's value.


Anyone has any idea how can I see if there was an IN packet sent out, or how can I carry on?

 

[Kripton2035]

icd2 887

may be you should connect a 877 to the PSP port of the 4550 to see what's coming through, and program the 877 with the bootloader we have ? may be the bytes you're waiting come from the EP2 and so the 877 ?

do you want me to send another log file of a precise condition ? by the way it's sure you need a rokaida log with his 4550 icd2..

PS: I'm not interested in that project.. I'm only curious ! I already have an usb icd2 !

 

[Zedman]

problema erase 18f4550

Thanks Kripton,

I'll notify you when I need more dump , It's a bit more complex than just passing through the bytes to 877 and back, it has a protocol wrapper on it.
What you said was very helpful, but rkodeira wont sacrify his brand new ICD2... If he would, than with the dump of it's OS update process would define the protocol well...

 

[Kripton2035]

18f4550 erase failed

well I dont think he needs to sacrify his icd2 !! only some dumps with usbmon like I did .. hopefully my icd2 is still working !!!

 

[albert22]

icd2 bootloader corrupt

I cannot install HHD monitor to see the logs because I only have w98 at home.
Can you export a dump of the OS download to a .txt, for me?
-------
How the CY resets the 877 ?
There is a signal (pin 43) to the base of Q1 whose Collector is MCLR. But this goes to a connector called PROG. I now realize that this signal should go to the 877 too.
We would need to know which USB command resets the 877. May be it is at one of the control endpoints?
I dont know what is the function of this PROG connector. but the extra endpoints may be related to it.
----------
One of the OS loaded to the ICD2 seems to be: ICD01020405.hex I have tried to disassemby it but I cannot get the disassembler to replace the hex addresses with the name of the registers. It will take more time to figure out how it works.
An interesting fact is that code starts at 0x0010. Remember that the BL calls this address with the execute command.

The BL version reported by mplab is 01.01.01.00 this goes fairly well with the BL command which answers 01,01,01,03
---------
There is no DPot (MCP41xxxx) in the Brazilian ICD. How do they set Vpp?
Most of the clones have a fixed Vpp. Does this means that the Brazilian ICD is just a low cost clone and not the new ICD2? I dont think that microchip went for a fixed vpp. If there is another method of controlling the vpp, other than the DPot it would need firmware changes of the ICD OS. The old OS would not work in the new one. That may be the cause that the DLL is checking the version.

 

[Zedman]

cypress firmware disassembling

I don't think we should deal with anything regarding the circuit or protocol or connection between 877 and 4550 yet. I think ALL we need is written in the 4550 bins supplied with MPLAB.
We should write a bootloader compatible with the icd2w2k.sys to get the OS.bin downloaded, and after that we can scracth our heads how the 877 is connected.

Added after 5 minutes:

In ICD2br uses another kind of chip which generates the Vpp. Rkodaira mentoined, check the posts before.

 

[silvio]

pic33f bootloader

We should write a bootloader compatible with the icd2w2k.sys to get the OS.bin downloaded.

Yes, this is the main reason for which I said that dissasembling CY fw it's useless as long as we have the OS and BL bin file provided by Microchip. To start coding from scratch for 4550 and simulate the CY fw would be time consuming and worthless.
That's I appreciate zedman's efforts.

However sometimes I can't help myself to ask this stupid question : If the BL cannot be upgraded while it's active, what was Microchip's ICD2 designers approach for upgrade ? In parallel programmer before soldering 4550 ? Or through ICSP with a clean bin image downloaded after boot block erased ?
If rkodaira will find that CPB and EBTRB bits are cleared , then how can OS.bin be loaded in 4550 ? I start asking like you : why did they supplied the boot image ?
Or, as Jay.slovak said "the string is readable, just the code does nothing" because it's encrypted and makes sense only for original boot code.
So, the only solution is to simulate the 4550's bootloader and get the mirror bin image of OS ?

 

[albert22]

how to burn a program using mplab 7.60 ??????????

In ICD2br uses another kind of chip which generates the Vpp. Rkodaira mentoined, check the posts before.

I didnt mean the MIC2175, which is a switching regulator as the MC34063. I was aiming at the DPOT and specifically to its I2C interfase because it requires the support of the firmware in the 877 to set the correct Vpp voltage. As I said before if the new ICD2 relies in other component to change the Vdd, all the firmware needs to change.

May be Rkodaira could check ithe circuit associated with pin 3 (FB) of the MIC2172 to see if vpp can be controlled or it is fixed.

Let me make my statement a little clear. If the Brazilian ICD has no control of Vpp it is highly probable that it is just a clone. In that case there is no warranty that the real new ICD2 is based on a 4550 and a 877. It could be just a 4450 alone for example (why not) in that case the following statement would not be true.

I think ALL we need is written in the 4550 bins supplied with MPLAB.

As we dont know for sure the arquitecture of the new ICD we need to emulate the CY. However chances are that the 4550BINs will still be usefull to solve the USB protocol. I tried to disassemble it today but found nothing coherent yet.

To the question:

why did they supplied the boot image ?

They supplied the BL010101.hex which needs to be programmed at the factory for the ICD to work.[/quote]