| Forfatter | Besked |
|---|
Kripton2035
Tilsluttet: 19. juli 2001
Posts: 482
Hjulpet: 15
Beliggenhed: Earth
|  03 april 2006 8:28 Re: Projekt til at erstatte CY7C64613 i ICD2 | | |
|
| | predrage wrote: | Mine venner jeg ikke lykkes i programmering ICD2_4550_BOOT_0180.BIN i 4550. I'v
forsøgt at åbne bin filen med winpic 800 software men det mislykkedes. Jeg tryed for at åbne det med option "alle filer" i "filtyper", fordi der ikke er nogen direkte støtte til bin filer. ICprog har at støtte (for at åbne bin filer), men kan ikke programmere 4550. I virkeligheden er der ingen 4550 i enheden listen. Hvad skal jeg gøre nu? Any suggestions? Jeg er bare en nybegynder, men jeg har gode vilje til at hjælpe.
Undskyld mit dårlige engelsk. |
omdøbe den. BIN til. HEX og winpic vil åbne det!
undertiden en masse filer. BIN i virkeligheden er Intel. hex!
at være sikker, skal du åbne filen med notesblok, hvis det indeholder linjer, der begynder med ":" og derefter omdøbe til. hex og åbne den med winpic .. hvis det affald, så en bin2hex skal bruges til at åbne den. |
|
| Tilbage til toppen | |
 |
narccizzo
Tilsluttet: 20. januar 2006
Stillinger: 173
Hjulpet: 4
Beliggenhed: PATZCUARO, Michoacán, Mexico
| | 03 april 2006 9:42 Re: Projekt til at erstatte CY7C64613 i ICD2 | | |
|
| Det er de to filer bin omdannes til hex, jeg har åbnet bin filer med
IC-PROG software så jeg gemme filerne i hex format, hvis du tager et kig på disse filer, du kan se en letlæselig string "Microchip Tecnology ICD2 USB Device icd2 usb" i adressefeltet 0x0ee7 for boot.hex fil og samme streng i 0x0b8e for
os.hex fil, jeg dont have en Disassembler at udforske en mere detaljeret beskrivelse af filer, men noget siger mig, at disse to filer er alt, hvad vi har brug for.
BR
Narccizzo
|
|
| Tilbage til toppen | |
|
Jay.slovak
Tilsluttet: 23. marts 2006
Stillinger: 11
| | 03 april 2006 11:17 Re: Projekt til at erstatte CY7C64613 i ICD2 | | |
|
| | narccizzo wrote: | Det er de to filer bin omdannes til hex, jeg har åbnet bin filer med
IC-PROG software så jeg gemme filerne i hex format, hvis du tager et kig på disse filer, du kan se en letlæselig string "Microchip Tecnology ICD2 USB Device icd2 usb" i adressefeltet 0x0ee7 for boot.hex fil og samme streng i 0x0b8e for
os.hex fil, jeg dont have en Disassembler at udforske en mere detaljeret beskrivelse af filer, men noget siger mig, at disse to filer er alt, hvad vi har brug for.
BR
Narccizzo |
Er du sikker på du har konverteret filerne korrekt? Hvis jeg importere dem til MPLAB, koden giver ikke mening, alt det gør, er bare gennem Program hukommelse og gør NOPs. Intet nyttige, der sker i både Boot og OS HEXs. Selv config bits er forskellige i både filer! |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 03 april 2006 11:19 Project at erstatte CY7C64613 i ICD2 | | |
|
| Albert,
kernel driver (s) forventer, at cypres vil slutte på en anden vid / pid når firt tilsluttet, og efter loader sys downloads er det fw det vil reconnect som en anden vid / pid så de andre sys samtaler til det. Vi er nødt til at gennemføre kun den anden.
Nu @ arbejde så jeg kan ikke gøre noget her forventer hårde thinkin '  ... |
|
| Tilbage til toppen | |
|
Silvio
Tilsluttet: 31. december 2001
Stillinger: 800
Hjulpet: 90
| | 03 april 2006 11:31 Re: Projekt til at erstatte CY7C64613 i ICD2 | | | tags: mplab protokol icd2 cypres Disassembler Disassembler cypres |
|
| Hi Zedman,
it's a must to understand what's under cover. Hvad angår CY hex fil det er ikke kun et spørgsmål om god Disassembler der kender cypres chip, men læsning af 436 sider EZ-USB FX TechRefManual det er et must for at forstå, hvad der er under tag.
Og jeg tror ikke du har tid til dette. Men hvis du ikke er bekendt med 8051 opcodes, parsing koden vil tage nogen tid. (Jeg ved, du er familar med PIC dem)
with appropiate values from CY7C64613 registers 0x7800-0x7FFF but you'll definitely end up turning the pages of TechRefManual looking for definitions. Jeg kan erstatte alle forekomsten af MOV DPTR, # LXXXX med passende værdier fra CY7C64613 registre 0x7800-0x7FFF men du vil helt sikkert ender med at vende siderne i TechRefManual søger definitioner.
Ud over at det ville nogle hvordan vanskeligt at tildele bits navne, der er indstillet, eller klart i programmet, så længe de ikke er kortlagt i SFR rummet (som slutter på 0 eller 8).
with MOV DPTR, #EP0CS but it's difficult to say SETB HSNAK due to the above reasons. Det er nemt at udskifte MOV DPTR, # L7FB4 med MOV DPTR, # EP0CS men det er svært at sige SETB HSNAK på grund af ovennævnte årsager.
and EP0STAL L which are affected in the bellow code at 0x03E2. Lad os tage eksemplet bits HSNAK og EP0STAL L, der er berørt i nedenstående kode på 0x03E2.
| Code: |
L03E2: LCALL L0FBE
Jnc L03EE
MOV DPTR, # L7FB4
MOVX A, @ DPTR
Oto-rhino-laryngologi A, # 01h; en slags SETB EP0STALL
MOVX @ DPTR, A
L03EE: MOV DPTR, # L7FB4
MOVX A, @ DPTR
Oto-rhino-laryngologi A, # 02h; en slags SETB HSNAK
MOVX @ DPTR, A
RET
L0FBE: SETB C
RET
|
Tag for eksempel (CP_1.asm) koden linjer startende med offset 0x0100 (a delrutinen forvandleTil kaldes fra 0x05FA), den første kode linje anvendes immediatelly nedenuden vektoren afbryder tabellen
På RAM 0x7FE9 kan du finde 2. byte af de 8 bytes USB SETUP pakkedata (se side 215 table9-1), hvilket betyder bRequest område (se tabel 9-2).
| Code: |
L0100: MOV DPTR, # L7FE9
MOVX A, @ DPTR
JNZ L0109
LJMP L029B; hvis bRequest = GetStatus springe til 0x029B
L0109: DEC A
JNZ L010F
LJMP L0317; hvis bRequest = Ryd Feature, springe til 0x0317
L010F: ADD A, # 0FEh
JNZ L0116
LJMP L038E; hvis bRequest = Set Feature, springe til 0x038E
L0116: ADD A, # 0FBh
JNZ L011D
LJMP L0295; hvis bRequest = Få Konfiguration, springe til 0x0295
L011D: DEC A
JNZ L0123
LJMP L028F; hvis bRequest = Indstil konfiguration, springe til 0x028F
L0123: DEC A
JNZ L0129
LJMP L0283; hvis bRequest = Få Interface, hoppe til 0x0283
L0129: DEC A
JNZ L012F
LJMP L0289; hvis bRequest = Indstil Interface, hoppe til 0x0289
L012F: ADD A, # 05h
JZ L0136
LJMP L03E2; hvis bRequest = ingen af de ovennævnte, derefter indstille bits HSNAK
; og EP0STALL af EP0CS kontrol & status register og
; derefter RET på 0x05FD
;
L0136: LCALL L0F7A; hvis bRequest = Få deskriptor, LCALL 0x0F7A hvor
JC L013E; carry bit er sat som standard, så spring til 0x013E
LJMP L03EE; hvis 0x0F7A carry ville være 0 som standard indstillet bit HSNAK
; af EP0CS kontrol & status register og RET på 0x05FD
;
L013E: MOV DPTR, # L7FEB; her, fordi bRequest var Få deskriptor
MOVX A, @ DPTR, og dermed kontrollere WValueH området USB SETUP packet
ADD A, # 0FEh
JZ L015F; hvis wValueH var 0x02 springe til 0x015F
DEC A
JZ L0190; hvis wValueH blev 0x03 springe til 0x0190
ADD A, # 02h
JZ L0150; hvis wValueH blev 0x01 springe til 0x0150
LJMP L0279; hvis wValueh er en anden af enten 0x01 eller 0x02 eller 0x03 derefter indstille
; bits HSNAK og EP0STALL af EP0CS register og RET på 0x05FD
;
L0150: MOV A, 0Ch; her, fordi wValueH var 0x01, så belastningen SUDPTR globale USB register
MOV DPTR, # L7FD4; med værdi 0x0C0D, derefter indstille bit HSNAK af EP0CS og RET på 0x05FD
MOVX @ DPTR, A
MOV A, 0Dh
MOV DPTR, # L7FD5
MOVX @ DPTR, A
LJMP L03EE
L015F: MOV DPTR, # L7FEA; ser nu på wValueL området USB SETUP packet
;
;
;
;
og så videre ...................
|
port2: Microchip MPLAB ICD2 Fw client Eller denne opslagstabelnavn på offset 0x0622 der matcher Kripton2035 port2: Microchip MPLAB ICD2 Fw klient
| Code: |
Tabel 5-9. USB standardenhed deskriptor
RAM Værdi Offset Felt Beskrivelse
0622 0x12 0 bLength Længde af denne deskriptor = 18 bytes
0623 0x01 1 bDescriptorType deskriptor Type = Enhed
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 Enhed klasse (FF er Vendor-specifik)
0627 0xFF 5 bDeviceSubClass Enhed Sub-Class (FF er Vendor-specifik)
0628 0xFF 6 bDeviceProtocol Device Protocol (FF er Vendor-specifik)
0629 0x40 7 bMaxPacketSize0 maksimale pakkestørrelse 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 Antal (BCD, L)
062F 0x00 13 bcdDevice (H) Enhedstype Release Antal (BCD, H)
0630 0x00 14 iManufacturer Producent Indeks String = Ingen
0631 0x00 15 iProduct Product Index String = Ingen
0632 0x00 16 iSerialNumber Serienummer Indeks String = Ingen
0633 0x01 17 bNumConfigurations Antal Konfigurationer i denne Interface = 1
Tabel 5-10. USB standardkonfiguration deskriptor
RAM Værdi Offset Felt Beskrivelse
0634 0x09 0 bLength Længde af denne deskriptor = 9 bytes
0635 0x02 1 bDescriptorType deskriptor Type = Configuration
0636 0x74 2 wTotalLength (L) Samlet længde (L) Herunder Interface og slutpunktsmapperen Deskriptorer = 116
0637 0x00 3 wTotalLength (H) Samlet længde (H)
0638 0x01 4 bNumInterfaces Antal Grænseflader i denne Configuration
0639 0x01 5 bConfigurationValue Konfiguration værdi, der anvendes ved Set_Configuration Anmodning at vælge denne Configuration
063A 0x00 6 iConfiguration Index of String beskriver denne Configuration = Ingen
063B 0x80 7 bmAttributes Attributter - Bus-Powered, nr. Wakeup
063C 0x4B 8 MaxPower Maximum Power - 150 mA
Tabel 5-11. USB Standard Interface 0, Alternate Setting 0 deskriptor
RAM Værdi Offset Felt Beskrivelse
063D 0x09 0 bLength Længde af Interface deskriptor
063E 0x04 1 bDescriptorType deskriptor Type = Interface
063F 0x00 2 bInterfaceNumber Nul-baserede Indeks over denne Interface = 0
0640 0x00 3 bAlternateSetting Alternate Indstilling Værdi = 0
0641 0x0E 4 bNumEndpoints Antal endepunkter i denne Interface (Ikke Optælling EPO) = 14
0642 0xFF 5 bInterfaceClass Interface klasse = Vendor Specific
0643 0xFF 6 bInterfaceSubClass Interface Sub-class = Vendor Specific
0644 0xFF 7 bInterfaceProtocol Interface protokol = Vendor Specific
0645 0x00 8 iInterface Indeks til String Deskriptoren for denne Interface = Ingen
Tabel 5-14. Standard Interface 0, Alternate Indstilling 1, Bulk slutpunktsmapperen Deskriptorer
RAM Værdi Offset Felt Beskrivelse
0646 0x07 0 bLength Længde fra dette endpoint deskriptor
0647 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0648 0x01 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT1
0649 0x02 3 bmAttributes XFR Type = BULK
064A 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
064B 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
064C 0x01 6 bInterval forespørgselsinterval i millisekunder
064D 0x07 0 bLength Længde fra dette endpoint deskriptor
064E 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
064F 0x02 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT2
0650 0x02 3 bmAttributes XFR Type = BULK
0651 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0652 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0653 0x01 6 bInterval forespørgselsinterval i millisekunder
0654 0x07 0 bLength Længde fra dette endpoint deskriptor
0655 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0656 0x03 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT3
0657 0x02 3 bmAttributes XFR Type = BULK
0658 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0659 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
065A 0x01 6 bInterval forespørgselsinterval i millisekunder
065B 0x07 0 bLength Længde fra dette endpoint deskriptor
065C 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
065D 0x04 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT4
065E 0x02 3 bmAttributes XFR Type = BULK
065F 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0660 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0661 0x01 6 bInterval forespørgselsinterval i millisekunder
0662 0x07 0 bLength Længde fra dette endpoint deskriptor
0663 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0664 0x05 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT5
0665 0x02 3 bmAttributes XFR Type = BULK
0666 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0667 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0668 0x01 6 bInterval forespørgselsinterval i millisekunder
0669 0x07 0 bLength Længde fra dette endpoint deskriptor
066A 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
066B 0x06 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT6
066C 0x02 3 bmAttributes XFR Type = BULK
066D 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
066E 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
066F 0x01 6 bInterval forespørgselsinterval i millisekunder
0670 0x07 0 bLength Længde fra dette endpoint deskriptor
0671 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0672 0x07 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = OUT7
0673 0x02 3 bmAttributes XFR Type = BULK
0674 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0675 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0676 0x01 6 bInterval forespørgselsinterval i millisekunder
RAM Værdi Offset Felt Beskrivelse
0677 0x07 0 bLength Længde fra dette endpoint deskriptor
0678 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0679 0x81 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN1
067A 0x02 3 bmAttributes XFR Type = BULK
067B 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
067C 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
067D 0x01 6 bInterval forespørgselsinterval i millisekunder
067E 0x07 0 bLength Længde fra dette endpoint deskriptor
067F 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0680 0x82 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN2
0681 0x02 3 bmAttributes XFR Type = BULK
0682 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0683 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0684 0x01 6 bInterval forespørgselsinterval i millisekunder
0685 0x07 0 bLength Længde fra dette endpoint deskriptor
0686 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0687 0x83 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN3
0688 0x02 3 bmAttributes XFR Type = BULK
0689 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
068A 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
068B 0x01 6 bInterval forespørgselsinterval i millisekunder
068C 0x07 0 bLength Længde fra dette endpoint deskriptor
068D 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
068E 0x84 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN4
068F 0x02 3 bmAttributes XFR Type = BULK
0690 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0691 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0692 0x01 6 bInterval forespørgselsinterval i millisekunder
0693 0x07 0 bLength Længde fra dette endpoint deskriptor
0694 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
0695 0x85 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN5
0696 0x02 3 bmAttributes XFR Type = BULK
0697 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
0698 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
0699 0x01 6 bInterval forespørgselsinterval i millisekunder
069A 0x07 0 bLength Længde fra dette endpoint deskriptor
069B 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
069C 0x86 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN6
069D 0x02 3 bmAttributes XFR Type = BULK
069E 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
069F 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
06A0 0x01 6 bInterval forespørgselsinterval i millisekunder
06A1 0x07 0 bLength Længde fra dette endpoint deskriptor
06A2 0x05 1 bDescriptor Type deskriptor Type = slutpunktsmapperen
06A3 0x87 2 bEndpointAddress slutpunktsmapperen Direction (1 er i) og adresse = IN7
06A4 0x02 3 bmAttributes XFR Type = BULK
06A5 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelse = 64 Bytes
06A6 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelse - Høj
06A7 0x01 6 bInterval forespørgselsinterval i millisekunder
som derefter følges op af unicode form af nul sluttede string
"Microchip Technology ICD2 USB Device"
|
Men hvis du går i stå med 4550 bin, kan jeg forsøge at hjælpe ved at tilføje kommentarer i CY ASM-fil. |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 03 april 2006 17:10 Re: Projekt til at erstatte CY7C64613 i ICD2 | | | tags: icd2.dll |
|
| Hi Silvio,
tak for det infos, lang tid siden jeg var nødt til at parse en bin filen kommer fra en eprom chip. Jeg har ikke selv nogen forarbejdningsvirksomheden type eller kredsløb. Men jeg var nødt til at finde, hvordan den behandler et hukommelseskort, og det er data.
Jeg gik ud fra det er en 8051 slags chip og prøvede en masse disassemblers, og endte med en 80C542 (I cant huske, hvilken en var det nøjagtigt) Jeg regnede den ud fra havnen numre og hvordan koden omhandler individuel havn ben.
Men det tog 2 uger dag og nat arbejde  for mig, masser af læsning / debugging / læring.
Det er derfor, jeg ønskede en assembler, hvad der er i stand til at gøre de ting du har nævnt i stedet for mig ... 
Tak igen Silvio.
-----------------------------
Nu begynder at tro på jer alle, i henhold til bin filer. Jeg har et forskningsprojekt i ICD2 dll og fandt ud af, at det kræver GETUSBDESCRIPTOR og kontrol numre i deskriptor, og hvis det passer nyere version ICD2 end jeg underskrevet i mit 4550's deskriptor, end den gør i en send4550image call!
Og ligeledes er der deskriptorerne i bin filer identisk med en Kripton uploadet.
En ting jeg ikke forstår det er hvorfor har de leveret boot image?
Og hvorfor ICD2.dll forsøger at hente denne fil? Hvis jeg kommer hjem, jeg vil prøve at indstille min deskriptorer for at matche en jeg fandt i skraldespanden og vil forsøge MPLAB om det.
Jeg tror, vi nærmer! 
Lagt efter 46 minutter:
Og der er en magisk ting i første btyes af boot bin: MCHP (mikrochip?)
Jeg har søgt efter det, hvis det senere (efter belastning) erstatter disse med reelle indgangssted GOTO eller st, men i ICD2.dll ikke.
Tilføjet efter 3 timer 34 minutter:
Kig på dette:
Jeg gjorde, hvad jeg sagde før, bare sæt versionsnummeret til newer den forventer og MPLAB forsøger at sende OS! (Selvfølgelig min fw er ikke en opstartsindlæser)
| Code: |
MPLAB ICD 2 Klar
Tilslutning til MPLAB ICD 2
ICD0289: Kunne ikke re-program ICD2 USB OS firmware.
ICD0021: Kan ikke få forbindelse med MPLAB ICD 2
MPLAB ICD 2 Klar
|
Anden startindlæseren bør arbejde, jeg vil prøve at gøre noget om natten. |
|
| Tilbage til toppen | |
|
narccizzo
Tilsluttet: 20. januar 2006
Stillinger: 173
Hjulpet: 4
Beliggenhed: PATZCUARO, Michoacán, Mexico
| | 03 april 2006 18:43 Project at erstatte CY7C64613 i ICD2 | | |
|
| Hi JaySlovak
Nej, Im ikke sikker på, jeg kun åbnede bin og gemme det i hex format.  |
|
| Tilbage til toppen | |
|
Jay.slovak
Tilsluttet: 23. marts 2006
Stillinger: 11
| | 03 april 2006 20:45 Re: Projekt til at erstatte CY7C64613 i ICD2 | | |
|
| | narccizzo wrote: | Hi JaySlovak
Nej, Im ikke sikker på, jeg kun åbnede bin og gemme det i hex format. |
Jep, det er mærkeligt som strengen er læsbare, blot koden betyder intet |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 03 april 2006 22:25 Re: Projekt til at erstatte CY7C64613 i ICD2 | | | tags: icd2.dll |
|
| Gode nyheder efter 2 timers debugging
ICD2.dll ikke bruge både af bin filer. OS fil ønsker at blive hentet kun ICD2s med nye produktets serienummer.
Men når du redigerer version id i filnavnet af OS.bin til * _FFFF.bin end det begynder at tjekke opstartsindlæseren version se ud:
| Code: |
Tilslutning til MPLAB ICD 2
ICDWarn0062: USB Boot firmware af ICD2 er aktiv og leverer kommunikation med ICD2. Denne firmware er forældede og bør ajourføres. Det kan ikke opdateres, mens aktive. Men du kan fortsætte med at operere med det nuværende boot firmware, hvis du vælger at gøre det. Vil du fortsætte?
|
Hvis jeg trykker JA her end den forsøger at forbinde til ICD2 sig selv, og fryser (jeg har kun 4550 installeret endnu).
Hvis jeg trykker på Nej, end det ser ud det forsøger at opdatere den, men vi har brug for her en opstartsindlæseren som dette, så denne besked vises:
| Code: |
ICD0288: Kunne ikke re-program ICD2 USB Boot firmware.
ICD0021: Kan ikke få forbindelse med MPLAB ICD 2
MPLAB ICD 2 Klar
|
Okay gutter, mener tror tror Hvordan kan vi bruge det bin at få en arbejdsgruppe opstartsindlæseren i 4550!
Lagt efter 2 minutter:
Jeg har også udarbejdet en prøve opstartsindlæseren med de korrekte VID / PID men fik de samme resultater som med min 4550.
Lagt efter 16 minutter:
Det kan være, at vi ikke kan få den første indledende indledende:) en del af opstartsindlæseren som belastninger første opstartsindlæseren som indlæser os ...
Lagt efter 5 minutter:
Dette er det tidspunkt, hvor rkodaira bør dump hans 4550 for de 0-plan opstartsindlæseren. (med et stort håb, som ikke er beskyttet ...)
Rkodaira Vi har brug for dig  |
|
| Tilbage til toppen | |
|
albert22
Tilsluttet: 20. juli 2004
Stillinger: 95
Hjulpet: 3
| | 03 april 2006 22:46 Re: Projekt til at erstatte CY7C64613 i ICD2 | | |
|
| Jeg har været at analysere en udskrift, som jeg har med mig i BL010101. og finde nogle ting.
Det ser ud til at acceptere 5 kommandoer kommer enten fra PSP eller USART.
0x55 Execute kode startende på 0x0010.
0x56 lastelinjer hex (dette ene synes at have mere subcommands)
0x5a sender dataene 0x01 0x01 0x03 (Version af BL????)
To andre kommandoer bare tænde Fejl og Optaget lysdioder og hænger i en inffinite sløjfe.
Følgende rutiner er relaterede til, hvad jeg kaldte den "belastning hex" kommandoen:
I en anden rutine BL sender følgende string 0x5b, "0810C9", 0x5d
Andre sender svar embeded i følgende string 0x5b, "0A000", U, 0x31, U, 0x5d. (hvor U synes at være 0x31, 0x34, 0x36 og 0x37).
Jeg gjorde ikke har meget tid til at fortsætte med analysen. Jeg hverken så USB-overvågning, der er blevet indsendt, fordi Im på et cyber. Men jeg mener, disse data skulle være pakket ind i USB-kommunikation |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 03 april 2006 23:30 Project at erstatte CY7C64613 i ICD2 | | |
|
| Albert,
Jeg undersøgte den serielle comm versus USB, USB bruger et dæksblad lavpunktet den serielle ting.
Det forekommer det bruger EP1 for kontrol port (it's OUT og IN) og EP2 som data port, kun IN (ICD-> PC). |
|
| Tilbage til toppen | |
|
albert22
Tilsluttet: 20. juli 2004
Stillinger: 95
Hjulpet: 3
| | 05 april 2006 6:39 Re: Projekt til at erstatte CY7C64613 i ICD2 | | |
|
| Her er mit forskud med BL
Der var ingen sådanne subcommands. Belastningen hex kommando bare tager hex optegnelser og skriver data til programmet hukommelse 2 bytes ad gangen. Det kontrol for forskellige fejl, herunder række adresse. Ap. at undgå at træde ind i den BL program. Dette bekræfter, at BL er altid hjemmehørende på 877.
De [0A000 ", U, 0x31, U]. (Den 2. U er den første U 1) er usandsynligt, at blive set, fordi det er en fejlrapport. Fejl omfatter: dårligt format, checksum, dårlig adresseområder og EEPROM skrive fejl .
De rutinemæssige venter på 16 tegn startende med en 0x3c ('<') og slutter med en 0x3e ('>'). denne 16 tegn header indeholder adresse, længde og kontrolsum for de data, der skal skrives i ASCII.
Hvis overskriften er korrekt Ap. BL svar med "[0810C9]"
De data cames efter en 0x7b
Denne model synes at være forskellige fra en Intel hex format.
Zedman.
Kan du genkendt noget lignende dette i RS232
Morgen Jeg wil være på mit hjem og i stand til at installere hdd at tjekke logs og se om jeg kan være til nogen hjælp. |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 05 april 2006 12:17 Re: Projekt til at erstatte CY7C64613 i ICD2 | | | tags: mplab protokol icd2 icd2.dll icd2w2k.sys mplbcomm.dll |
|
| Jeg sidder med denne USB ting. Og jeg er ked.
Jeg ved ikke rigtig ved hvad de skal gøre næste. Jeg brugte en masse tid debugging de icd2.dll.
Problemet er: Jeg kan ikke sende endnu en byte tilbage til MPLAB.
Jeg vil forklare, hvad jeg har fundet indtil nu, selv om ingen rigtig interesseret i (bare ønsker at få fat i det færdige ting). (Undtagen: Albert, Kripton, rkodaira, Silvio og fyre i denne tråd)
Så MPLAB kommunikerer med ICD2 denne måde:
[MPLAB -> ICD2.dll -> MPLBCOMM.dll -> icd2w2k.sys ->] --- [ICD2 enhed]
Hvis du vælger USB type forbindelse det vil anmode enheden deskriptor fra ICD2 og kontrol for produktet version ordet, hvis det 0x0003 end det er en Cypress baseret ICD2, hvis det 0x0010 end det er en 4550 baseret en. Hvis 0x0010 fundet end den siger, hvad jeg har været indsendt inden denne OS i ICD2 skal opgraderes. Det er interessant, at hvis den version (0100) i filnavnet til OS.bin er modificeret til at FFFF end det springer dette trin over og kontrollerer opstartsindlæseren version. Her var jeg nødt til at lappe ICD2.dll at få det prøv at tjekke BL.bin filens version Også det hardcodede, at selv det er indstillet til FFFF det plejer forsøger at opgradere, så derfor har jeg lappet den (sæt hardcodede FFFF til lavere), så nu siger, hvad jeg mentoined Også før: BL version er for gammel, men det kan ikke blive opgraderet, mens den aktive.
Okay. Jeg lavede en lille PROG fra prøven opstartsindlæseren, med de korrekte betegnelser og forsøger at kommunikere med MPLAB for at dekryptere den protokol, og at emulere BL i den nye 4550 ICD2.
ICD2 at Kripton anvendelser, (cypres version) indeholder 7 OUT / IN endpoints, men ifølge de logger det bruger kun EP1 til IN / OUT og EP2 for IN. (OUT betyder PC-> Device)
Det synes det sender usb specifikke kommandoer og data via EP1 ud, og tilbage på EP1 i og sender bytes readed fra ICD2's 877 gennem særskilte endpoint EP2 i.
Når MPLAB forsøger at sende th OS.bin at opgradere fw os det spørgsmål en getUSBdescriptor opkald til kernen føreren, og sender et 0x12 bytes lang kommando vha. DeviceIOControl kommando. Jeg debugged, den ankommer held til 4550.
End MPLAB spørgsmål en GetStatus opkald, og det ser ud fra indkaldelsen parametre at det forventer 0x08 bytes af data tilbage.
Jeg oprette mine buffer med 8 bytes og indstille ejerskab til SIE. Men det aldrig sender at 8 byte tilbage (den vises ikke i USBMon). Bare venter.
Der kan være mange ting.
Måske jeg st galt med opsætningen af 4550, men jeg prøvede det med en anden progs og det virker, kan sende bytes tilbage.
Jeg ved, at værten skal sende og IN kommando at lade enheden sender i, hvad det vil.
Men når jeg debugged MBLBCOMM, jeg så, at den DeviceIOControl kommando mislykkedes!
Jeg tought at måske nogle efterretninger blev bygget til. Sys fil og det dråber pakken, fordi det er forkert indhold, men jeg tror, det bør være et højere niveau opgave.
Når jeg kommer hjem I'll tjekke Getlasterror værdi.
Alle har en idé om hvordan kan jeg se, om der var en pakke sendt ud, eller hvordan kan jeg udføre? |
|
| Tilbage til toppen | |
|
Kripton2035
Tilsluttet: 19. juli 2001
Posts: 482
Hjulpet: 15
Beliggenhed: Earth
| | 05 april 2006 16:59 Project at erstatte CY7C64613 i ICD2 | | |
|
| kan du skal tilslutte en 877 til PSP havn i 4550 for at se, hvad der er på vej igennem, og programmere 877 med opstartsindlæseren vi har? kan være bytes du venter kommer fra EP2 og så 877?
vil du have mig til at sende en anden log-fil med en præcis tilstand? af den måde, den er sikker på, at du har brug for en rokaida log med sine 4550 icd2 ..
PS: Jeg er ikke interesseret i, at projektet .. Jeg er blot nysgerrig! Jeg har allerede en usb icd2! |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 05 april 2006 20:08 Project at erstatte CY7C64613 i ICD2 | | |
|
| Takket Kripton,
Jeg vil give dig besked, når jeg har brug for mere dump , Det er en smule mere kompliceret end blot passerer gennem bytes til 877 og tilbage, har det en protokol dæksblad på det.
Hvad du sagde, var meget hjælpsom, men rkodeira plejer sacrify hans splinternye ICD2 ... Hvis han ville, end med dump af det OS opdateringen ville definere protokol godt ... |
|
| Tilbage til toppen | |
|
Kripton2035
Tilsluttet: 19. juli 2001
Posts: 482
Hjulpet: 15
Beliggenhed: Earth
| | 05 april 2006 22:09 Project at erstatte CY7C64613 i ICD2 | | |
|
| | og jeg dont mener, at han er nødt til at sacrify hans icd2!! kun nogle lossepladser med usbmon ligesom jeg gjorde .. forhåbentlig min icd2 stadig arbejder! |
|
| Tilbage til toppen | |
|
albert22
Tilsluttet: 20. juli 2004
Stillinger: 95
Hjulpet: 3
| | 05 april 2006 22:16 Re: Projekt til at erstatte CY7C64613 i ICD2 | | | tags: icd2 belastning hex kommando |
|
| Jeg kan ikke installere HHD overvåge at se logfilerne, fordi jeg kun har w98 derhjemme.
Kan du eksportere en dump af OS download til en. Txt, for mig?
-------
Hvordan CY nulstiller 877?
Der er et signal (pin 43) til bunden af Q1 hvis Samlermønter er MCLR. Men det går til et stik kaldet PROG. Jeg er nu klar over, at dette signal skal gå til de 877 også.
Vi ville være nødt til at vide, hvilke USB-kommando nulstiller 877. Kan det på en af de kontrolforanstaltninger endpoints?
Jeg dont kende hvad er funktionen af denne PROG stik. men de ekstra endepunkter kan være relateret til det.
----------
En af de OS lastet til den ICD2 synes at være: ICD01020405.hex jeg har forsøgt at disassemby det, men jeg kan ikke få Disassembler at erstatte hex-adresser med navnet på den registre. Det vil tage mere tid til at regne ud, hvordan det fungerer.
Et interessant faktum er, at koden starter ved 0x0010. Husk, at BL opkald denne adresse med fuldbyrde kommando.
BL version rapporteret ved mplab er 01.01.01.00 dette går ganske godt med BL-kommando, der svarer på 01,01,01,03
---------
Der er ingen DPot (MCP41xxxx) i den brasilianske ICD. Hvordan kan de sætter Vpp?
De fleste af de kloner har en fast Vpp. Betyder dette, at den brasilianske ICD er bare en billig klon og ikke de nye ICD2? I dont tror, at mikrochip gik for en fast vpp. Hvis der er en anden metode til at kontrollere vpp, bortset fra DPot vil det være nødvendigt firmware ændringer af ICD OS. Den gamle OS ville ikke arbejde i den nye. Det kan være årsagen, at den DLL er at kontrollere versionen. |
|
| Tilbage til toppen | |
|
Zedman
Tilsluttet: 13. oktober 2003
Posts: 294
Hjulpet: 2
| | 05 april 2006 22:32 Project at erstatte CY7C64613 i ICD2 | | | tags: mplab protokol icd2 icd2w2k.sys icd2w2k hente 4550 opstartsindlæseren skrive icd2w2k.sys Download Download icd2w2k |
|
| Jeg tror ikke, vi bør beskæftige sig med noget vedrørende kredsløb eller protokol eller forbindelsen mellem 877 og 4550 endnu. Jeg tror alt, hvad vi har brug for, er skrevet i 4550 siloer leveres med MPLAB.
Vi bør skrive en opstartsindlæseren forenelig med icd2w2k.sys at få OS.bin hentet, og efter at vi kan scracth vores hoveder, hvordan de 877 er tilsluttet.
Lagt efter 5 minutter:
I ICD2br bruger en anden form for chip, der frembringer den Vpp. Rkodaira mentoined, tjekke stillinger før. |
|
| Tilbage til toppen | |
|
Silvio
Tilsluttet: 31. december 2001
Stillinger: 800
Hjulpet: 90
| | 06 april 2006 2:36 Re: Projekt til at erstatte CY7C64613 i ICD2 | | | tags: icd2w2k.sys icd2w2k hente 4550 opstartsindlæseren skrive icd2w2k.sys Download Download icd2w2k |
|
| | Zedman wrote: |
Vi bør skrive en opstartsindlæseren forenelig med icd2w2k.sys at få OS.bin downloadet.
|
Ja, dette er den vigtigste grund til, som jeg sagde, at dissasembling CY fw det er ubrugeligt, så længe vi har den OS og BL bin fil fra Microchip. Du kan starte kodning fra bunden i 4550 og simulere CY fw ville være tidskrævende og værdiløs.
Det er jeg værdsætter zedman's bestræbelser.
Men nogle gange kan jeg ikke hjælpe mig til at stille dette dumt spørgsmål: Hvis BL ikke kan moderniseres, mens den aktive, hvad var Microchip's ICD2 designere fremgangsmåde for opgraderingen? Sideløbende programmør før lodning 4550? Eller gennem ICSP med en ren bin billede hentet efter boot blokere slettes?
Hvis rkodaira vil finde, at CPB og EBTRB bits er ryddet  , 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 ? |
|
| Tilbage til toppen | |
|
albert22
Joined: 20 Jul 2004
Posts: 95
Helped: 3
| | 06 Apr 2006 4:36 Re: Project to replace CY7C64613 in the ICD2 | | | tags: mplab protocol icd2 |
|
| | Quote: | 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.
| Quote: | | 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:
| Quote: | | 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] |
|
| Tilbage til toppen | |
|
Zedman
Joined: 13 Oct 2003
Posts: 294
Helped: 2
| | 06 Apr 2006 11:48 Re: Project to replace CY7C64613 in the ICD2 | | | tags: icd2 load hex command |
|
| 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. |
|
| Tilbage til toppen | |
|
rkodaira
Joined: 08 Jun 2004
Posts: 332
Helped: 54
Location: Sao Paulo - Brasil
| | 06 Apr 2006 14:19 Re: Project to replace CY7C64613 in the ICD2 | | |
|
| 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. |
|
| Tilbage til toppen | |
|
albert22
Joined: 20 Jul 2004
Posts: 95
Helped: 3
| | 06 Apr 2006 18:26 Re: Project to replace CY7C64613 in the 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 |
|
| Tilbage til toppen | |
|
Kripton2035
Joined: 19 Jul 2001
Posts: 482
Helped: 15
Location: Earth
| | 06 Apr 2006 19:31 Re: Project to replace CY7C64613 in the ICD2 | | |
|
| | rkodaira wrote: | 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...
http://www.perisoft.net/bushound/
zedman needs a log of a real 4550... my cypress clone doesnt give all he needs... |
|
| Tilbage til toppen | |
|
Zedman
Joined: 13 Oct 2003
Posts: 294
Helped: 2
| | 06 Apr 2006 20:14 Project to replace CY7C64613 in the ICD2 | | |
|
| | It can be exported from USBMon to HTML format, but I have only serial ICD2. |
|
| Tilbage til toppen | |
|
Brem
Joined: 06 Apr 2006
Posts: 36
| | 06 Apr 2006 20:22 Re: Project to replace CY7C64613 in the ICD2 | | | tags: mplab protocol icd2 icd2 load hex command |
|
| 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 (?) . |
|
| Tilbage til toppen | |
|
albert22
Joined: 20 Jul 2004
Posts: 95
Helped: 3
| | 06 Apr 2006 23:17 Re: Project to replace CY7C64613 in the ICD2 | | |
|
| | Quote: | | 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. |
|
| Tilbage til toppen | |
|
Zedman
Joined: 13 Oct 2003
Posts: 294
Helped: 2
| | 06 Apr 2006 23:29 Re: Project to replace CY7C64613 in the ICD2 | | | tags: mplbcomm.dll |
|
| Hey Brem!
nice to see you here!
Thanks for the infos on the protocol.
| Quote: |
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.
-------------------
Iam now trying an alternate way to **** 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... |
|
| Tilbage til toppen | |
|
Brem
Joined: 06 Apr 2006
Posts: 36
| | 07 Apr 2006 0:31 Re: Project to replace CY7C64613 in the ICD2 | | |
|
| 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. |
|
| Tilbage til toppen | |
|
Zedman
Joined: 13 Oct 2003
Posts: 294
Helped: 2
| | 07 Apr 2006 10:51 Project to replace CY7C64613 in the ICD2 | | |
|
| 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
|
|
|
| Tilbage til toppen | |
|
