| Forfatter | Melding |
|---|
Kripton2035
Registrert: 19. juli 2001
Innlegg: 482
Hjalp: 15
Bosted: Earth
|  03 april 2006 8:28 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | |
|
| | predrage wrote: | Mine venner jeg ikke lykkes i programmering ICD2_4550_BOOT_0180.BIN i 4550. I'v
prøvde å åpne bin fil med winpic 800 programvare men det mislyktes. Jeg tryed å åpne den med alternativet "alle filer" i "Filtyper" fordi det ikke er noen direkte støtte til bin filer. ICprog har som støtter (åpne bin filer), men kan ikke programmere 4550. Faktisk er det ingen 4550 i enhetslisten. What should i do next? Noen forslag? Jeg er bare en nybegynner, men jeg har god vilje til å hjelpe.
Beklager min dårlige engelsk. |
endre navn på. BIN til. HEX og winpic vil åpne den!
noen ganger mange filer. BIN i virkeligheten er Intel. hex!
å være sikker på å åpne filen med notepad, hvis den inneholder linjer som begynner med ":" endre navn til. hex og åpne den med winpic .. om det er søppel, og en bin2hex må brukes for å åpne den. |
|
| Tilbake til toppen | |
 |
narccizzo
Registrert: 20. januar 2006
Innlegg: 173
Hjalp: 4
Beliggenhet: PATZCUARO, Michoacán, Mexico
| | 03 april 2006 9:42 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | |
|
| Dette er de to filer bin konverteres til heksadesimal, jeg har åpnet bin filer med
ic-prog programvare deretter lagrer jeg filene i hex-format, hvis du tar en titt på disse filene, kan du se en lesbar string "Microchip Tecnology ICD2 USB Device icd2 usb" i adressen 0x0ee7 for boot.hex fil og samme strengen i 0x0b8e for
os.hex fil, jeg dont har disassembler å utforske nærmere denne filer, men noe sier meg at disse to filene er alt vi trenger.
BR
Narccizzo
|
|
| Tilbake til toppen | |
|
Jay.slovak
Registrert: 23. mars 2006
Innlegg: 11
| | 03 april 2006 11:17 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | |
|
| | narccizzo wrote: | Dette er de to filer bin konverteres til heksadesimal, jeg har åpnet bin filer med
ic-prog programvare deretter lagrer jeg filene i hex-format, hvis du tar en titt på disse filene, kan du se en lesbar string "Microchip Tecnology ICD2 USB Device icd2 usb" i adressen 0x0ee7 for boot.hex fil og samme strengen i 0x0b8e for
os.hex fil, jeg dont har disassembler å utforske nærmere denne filer, men noe sier meg at disse to filene er alt vi trenger.
BR
Narccizzo |
Er du sikker på at du har konvertert filene riktig? Hvis jeg importere dem til MPLAB at koden ikke gir mening, all den gjør er bare å gå gjennom den Program minne og gjør NOPs. Ingenting nyttig som skjer i både Boot og OS HEXs. Selv config biter er forskjellige i både filer! |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 03 april 2006 11:19 Project erstatte CY7C64613 i ICD2 | | |
|
| Albert,
kjernen sjåfør (er) forventer at Cypress vil koble på en annen vid / pid når firt tilkoblet, og etter loader sys downloads det fw det igjen som en vid / pid så den andre sys snakker til den. Vi har å implementere bare den andre.
Engasjert @ work så jeg kan ikke gjøre noe her forvente hard tenkte  ... |
|
| Tilbake til toppen | |
|
Silvio
Registrert: 31. desember 2001
Innlegg: 800
Hjalp: 90
| | 03 april 2006 11:31 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | | tags: mplab protokollen icd2 Cypress disassembler disassembler Cypress |
|
| Hi Zedman,
it's a must to understand what's under cover. Angående CY hex fil det er ikke bare et spørsmål om god disassembler som kjenner Cypress chip, men lesing av 436 sider EZ-USB FX TechRefManual det er en nødvendighet for å forstå hva som er under tak.
Og jeg tror ikke du har tid til dette. Likevel, hvis du ikke er kjent med 8051 opcodes, analyseproblemer koden vil ta litt tid. (Jeg vet du familar med PIC Ones)
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 av MOV DPTR, # LXXXX med verdier fra CY7C64613 registrerer 0x7800-0x7FFF men du vil definitivt havne snu sidene av TechRefManual leter etter definisjoner.
Utenom at det ville noen hvor vanskelig å tildele biter navnene som er angitt eller klare i programmet så lenge de ikke er kartlagt i SFR plass (som ender på 0 eller 8).
with MOV DPTR, #EP0CS but it's difficult to say SETB HSNAK due to the above reasons. Det er lett å erstatte MOV DPTR, # L7FB4 med MOV DPTR, # EP0CS men det er vanskelig å si SETB HSNAK på grunn av ovennevnte årsaker.
and EP0STAL L which are affected in the bellow code at 0x03E2. La oss ta et eksempel biter HSNAK og EP0STAL L som er berørt i Bellow koden på 0x03E2.
| Code: |
L03E2: LCALL L0FBE
JNC L03EE
MOV DPTR, # L7FB4
MOVX A, @ DPTR
Orl A, # 01h; en slags SETB EP0STALL
MOVX @ DPTR, A
L03EE: MOV DPTR, # L7FB4
MOVX A, @ DPTR
Orl A, # 02h; en slags SETB HSNAK
MOVX @ DPTR, A
RET
L0FBE: SETB C
RET
|
Ta for eksempel (CP_1.asm) koden linjer som begynner med offset 0x0100 (a subroutine kalles fra 0x05FA), den første koden linje brukes immediatelly Bellow vektoren avbruddsordrelinje tabellen
På RAM 0x7FE9 finner du 2dre byte av 8 bytes USB SETUP pakkedata (se side 215 table9-1), som betyr bRequest feltet (se tabell 9-2).
| Code: |
L0100: MOV DPTR, # L7FE9
MOVX A, @ DPTR
JNZ L0109
LJMP L029B; hvis bRequest = GetStatus hoppe til 0x029B
L0109: DEC A
JNZ L010F
LJMP L0317; hvis bRequest = Clear Feature, hoppe til 0x0317
L010F: ADD A, # 0FEh
JNZ L0116
LJMP L038E; hvis bRequest = Set Feature, hoppe til 0x038E
L0116: ADD A, # 0FBh
JNZ L011D
LJMP L0295; hvis bRequest = Få Configuration, hoppe til 0x0295
L011D: DEC A
JNZ L0123
LJMP L028F; hvis bRequest = Angi konfigurasjon, hoppe 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 = Set Interface, hoppe til 0x0289
L012F: ADD A, # 05H
JZ L0136
LJMP L03E2; hvis bRequest = ingen av disse, og deretter sette bitene HSNAK
og EP0STALL av EP0CS kontroll og status registrere og
; deretter RET på 0x05FD
;
L0136: LCALL L0F7A; hvis bRequest = Få beskrivelse, LCALL 0x0F7A der
JC L013E; bære bit er satt som standard, så gå til 0x013E
LJMP L03EE; om i 0x0F7A bære ville være 0 som standard satt bit HSNAK
; av EP0CS kontroll og status registrere og RET på 0x05FD
;
L013E: MOV DPTR, # L7FEB; her fordi bRequest var Få beskrivelse
MOVX A, @ DPTR; derfor sjekke WValueH feltet USB SETUP pakkefilter
ADD A, # 0FEh
JZ L015F; hvis wValueH var 0x02 hoppe til 0x015F
DEC A
JZ L0190; hvis wValueH var 0x03 hoppe til 0x0190
ADD A, # 02h
JZ L0150; hvis wValueH var 0x01 hoppe til 0x0150
LJMP L0279; hvis wValueh er forskjellig enten 0x01 eller 0x02 eller 0x03 deretter angi
; biter HSNAK og EP0STALL av EP0CS registrere og RET på 0x05FD
;
L0150: MOV A, 0Ch; her fordi wValueH var 0x01, så last SUDPTR globale USB register
MOV DPTR, # L7FD4; med verdien 0x0C0D, og deretter sette bit HSNAK av EP0CS og RET på 0x05FD
MOVX @ DPTR, A
MOV A, 0Dh
MOV DPTR, # L7FD5
MOVX @ DPTR, A
LJMP L03EE
L015F: MOV DPTR, # L7FEA; ser nå på wValueL feltet USB SETUP pakkefilter
;
;
;
;
og så videre ...................
|
port2: Microchip MPLAB ICD2 Fw client Eller denne søketabellen på offset 0x0622 som tilsvarer Kripton2035 port2: Microchip MPLAB ICD2 Vs klient
| Code: |
Tabell 5-9. USB Standardenhet beskrivelse
RAM Verdi Offset Felt Beskrivelse
0622 0x12 0 bLength Lengde av denne beskrivelse = 18 bytes
0623 0x01 1 bDescriptorType beskrivelse Type = Enhet
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 Enhet Klassifikasjon (FF er Vendor-Specific)
0627 0xFF 5 bDeviceSubClass Enhet Sub-Class (FF er Vendor-Specific)
0628 0xFF 6 bDeviceProtocol Enhet Protocol (FF er Vendor-Specific)
0629 0x40 7 bMaxPacketSize0 maksimale pakkestørrelsen 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 Produsentlinker Indekssøk String = Ingen
0631 0x00 15 iProduct Product Index String = Ingen
0632 0x00 16 iSerialNumber Serienummer Index String = Ingen
0633 0x01 17 bNumConfigurations Antall konfigurasjoner i denne Interface = 1
Tabell 5-10. USB Standard Configuration beskrivelse
RAM Verdi Offset Felt Beskrivelse
0634 0x09 0 bLength Lengde av denne beskrivelse = 9 bytes
0635 0x02 1 bDescriptorType beskrivelse Type = Configuration
0636 0x74 2 wTotalLength (L) Total lengde (L) Inkludert Interface og endepunkt beskrivere = 116
0637 0x00 3 wTotalLength (H) Total lengde (H)
0638 0x01 4 bNumInterfaces Antall Interfaces i denne konfigurasjonen
0639 0x01 5 bConfigurationValue Konfigurasjonsredigering verdien som brukes av Set_Configuration Request for å velge dette Configuration
063A 0x00 6 iConfiguration Index of String beskriver denne Configuration = Ingen
063B 0x80 7 bmAttributes Attributter - Buss-Powered, No reaktivering
063C 0x4B 8 MaxPower Maks effekt - 150 mA
Tabell 5-11. USB Standard Interface 0, Alternate Innstilling 0 beskrivelse
RAM Verdi Offset Felt Beskrivelse
063D 0x09 0 bLength Length av Interface beskrivelse
063E 0x04 1 bDescriptorType beskrivelse Type = Interface
063F 0x00 2 bInterfaceNumber Zero-baserte Indeks av dette grensesnittet = 0
0640 0x00 3 bAlternateSetting Alternate Innstilling Value = 0
0641 0x0E 4 bNumEndpoints Antall endepunkter i denne Interface (utenom 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 til String beskrivelse av dette grensesnittet = Ingen
Tabell 5-14. Standard Interface 0, Alternate Innstilling 1, Bulk endepunktet beskrivere
RAM Verdi Offset Felt Beskrivelse
0646 0x07 0 bLength Length av dette endepunktet beskrivelse
0647 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0648 0x01 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = OUT1
0649 0x02 3 bmAttributes XFR Type = Bulk
064A 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
064B 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
064C 0x01 6 bInterval avspørringsintervall i millisekunder
064D 0x07 0 bLength Length av dette endepunktet beskrivelse
064E 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
064F 0x02 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = OUT2
0650 0x02 3 bmAttributes XFR Type = Bulk
0651 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0652 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0653 0x01 6 bInterval avspørringsintervall i millisekunder
0654 0x07 0 bLength Length av dette endepunktet beskrivelse
0655 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0656 0x03 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = OUT3
0657 0x02 3 bmAttributes XFR Type = Bulk
0658 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0659 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
065A 0x01 6 bInterval avspørringsintervall i millisekunder
065B 0x07 0 bLength Length av dette endepunktet beskrivelse
065C 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
065D 0x04 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = OUT4
065E 0x02 3 bmAttributes XFR Type = Bulk
065F 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0660 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0661 0x01 6 bInterval avspørringsintervall i millisekunder
0662 0x07 0 bLength Length av dette endepunktet beskrivelse
0663 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0664 0x05 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = OUT5
0665 0x02 3 bmAttributes XFR Type = Bulk
0666 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0667 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0668 0x01 6 bInterval avspørringsintervall i millisekunder
0669 0x07 0 bLength Length av dette endepunktet beskrivelse
066A 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
066B 0x06 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = OUT6
066C 0x02 3 bmAttributes XFR Type = Bulk
066D 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
066E 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
066F 0x01 6 bInterval avspørringsintervall i millisekunder
0670 0x07 0 bLength Length av dette endepunktet beskrivelse
0671 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0672 0x07 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = OUT7
0673 0x02 3 bmAttributes XFR Type = Bulk
0674 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0675 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0676 0x01 6 bInterval avspørringsintervall i millisekunder
RAM Verdi Offset Felt Beskrivelse
0677 0x07 0 bLength Length av dette endepunktet beskrivelse
0678 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0679 0x81 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = IN1
067A 0x02 3 bmAttributes XFR Type = Bulk
067B 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
067C 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
067D 0x01 6 bInterval avspørringsintervall i millisekunder
067E 0x07 0 bLength Length av dette endepunktet beskrivelse
067F 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0680 0x82 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = IN2
0681 0x02 3 bmAttributes XFR Type = Bulk
0682 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0683 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0684 0x01 6 bInterval avspørringsintervall i millisekunder
0685 0x07 0 bLength Length av dette endepunktet beskrivelse
0686 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0687 0x83 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = IN3
0688 0x02 3 bmAttributes XFR Type = Bulk
0689 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
068A 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
068B 0x01 6 bInterval avspørringsintervall i millisekunder
068C 0x07 0 bLength Length av dette endepunktet beskrivelse
068D 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
068E 0x84 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = IN4
068F 0x02 3 bmAttributes XFR Type = Bulk
0690 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0691 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0692 0x01 6 bInterval avspørringsintervall i millisekunder
0693 0x07 0 bLength Length av dette endepunktet beskrivelse
0694 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
0695 0x85 2 bEndpointAddress endepunkt Direction (1 er i) og Adresse = IN5
0696 0x02 3 bmAttributes XFR Type = Bulk
0697 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
0698 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
0699 0x01 6 bInterval avspørringsintervall i millisekunder
069A 0x07 0 bLength Length av dette endepunktet beskrivelse
069B 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
069C 0x86 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = IN6
069D 0x02 3 bmAttributes XFR Type = Bulk
069E 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
069F 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
06A0 0x01 6 bInterval avspørringsintervall i millisekunder
06A1 0x07 0 bLength Length av dette endepunktet beskrivelse
06A2 0x05 1 bDescriptor Type beskrivelse Type = endepunktet
06A3 0x87 2 bEndpointAddress endepunktet Direction (1 er i) og Adresse = IN7
06A4 0x02 3 bmAttributes XFR Type = Bulk
06A5 0x40 4 wMaxPacketSize (L) maksimale pakkestørrelsen = 64 Bytes
06A6 0x00 5 wMaxPacketSize (H) maksimale pakkestørrelsen - Høy
06A7 0x01 6 bInterval avspørringsintervall i millisekunder
som deretter følges av unicode form av null endte string
"Microchip Technology ICD2 USB Device"
|
Men hvis du får problemer med 4.550 bin, kan jeg forsøke å hjelpe ved å legge til kommentarer i CY asm fil. |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 03 april 2006 17:10 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | | tags: icd2.dll |
|
| Hi Silvio,
Takk for info, lenge siden jeg måtte analysere en bin-filen kommer fra en EPROM brikken. Jeg hadde ikke selv ingen prosessoren type eller krets. Men jeg måtte finne ut hvordan det avtaler med et minnekort, og det er data.
Jeg antar det er en 8051 slags chip og prøvd mye disassemblers, og endte opp med en 80C542 (i cant huske hvem var det nøyaktig) Jeg skjønte det ut fra portnumre og hvordan koden omhandler individuell port pins.
Men det tok 2 uker dag og natt arbeid  for meg, mye lesing / debugging / læring.
Det er derfor jeg ønsket en Assembler hva som er i stand til å gjøre de tingene du nevnte stedet meg ... 
Thanks again Silvio.
-----------------------------
Engasjert begynner å tro dere alle, i henhold til bin filer. Jeg gjorde et forskningsinstitutt i ICD2 dll og funnet ut at det samtaler GETUSBDESCRIPTOR og sjekker numrene i beskrivelse og hvis det stemmer med nyere versjon ICD2 enn jeg logget på min 4550's beskrivelse enn den gjør en send4550image samtale!
Og også det er beskrivelsene i bin filer identisk med en Kripton opplastet.
En ting jeg ikke forstår det er derfor har de levert oppstartspartisjonen bildet?
Og hvorfor ICD2.dll prøver å laste ned denne filen? Hvis jeg kommer hjem, vil jeg prøve å sette mitt beskrivere å matche den jeg fant i bin og vil forsøke MPLAB på den.
Jeg tror vi nærmer! 
Lagt til etter 46 minutter:
Og det er en magisk ting i første btyes av boot bin: MCHP (Microchip?)
Jeg har søkt etter den, hvis det senere (etter Beregnigner) erstatter disse med ekte inngangspunktet GOTO eller st, men i ICD2.dll ikke.
Lagt til etter 3 timer 34 minutter:
Se på dette:
Jeg gjorde det jeg sa før, bare sett versjonsnummeret til nyere det regner og MPLAB prøver å sende OS! (Selvfølgelig min fw er ikke en oppstartslastingen)
| Code: |
MPLAB ICD 2 Ready
Koble til MPLAB ICD 2
ICD0289: Kan ikke re-programmet ICD2 USB OS fastvare.
ICD0021: Kan ikke koble til med MPLAB ICD 2
MPLAB ICD 2 Ready
|
Annen oppstartslastingen bør arbeide, vil jeg prøve å gjøre noe på kvelden. |
|
| Tilbake til toppen | |
|
narccizzo
Registrert: 20. januar 2006
Innlegg: 173
Hjalp: 4
Beliggenhet: PATZCUARO, Michoacán, Mexico
| | 03 april 2006 18:43 Project erstatte CY7C64613 i ICD2 | | |
|
| Hi JaySlovak
Nei, Im ikke sikker, jeg bare åpnet bin og lagre den i hex format.  |
|
| Tilbake til toppen | |
|
Jay.slovak
Registrert: 23. mars 2006
Innlegg: 11
| | 03 april 2006 20:45 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | |
|
| | narccizzo wrote: | Hi JaySlovak
Nei, Im ikke sikker, jeg bare åpnet bin og lagre den i hex format. |
Jepp, det er rart så strengen er lesbar, bare koden betyr ingenting |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 03 april 2006 22:25 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | | tags: icd2.dll |
|
| Gode nyheter etter 2 timer med debugging
ICD2.dll bruker begge bin filer. OS-filen vil bli lastet ned bare for ICD2s med nye produktets serienummer.
Men når du endrer versjonen id i filnavn OS.bin til * _FFFF.bin enn det begynner å se bootloader versjonen se ut:
| Code: |
Koble til MPLAB ICD 2
ICDWarn0062: USB Boot firmware av ICD2 er aktiv og gir kommunikasjon med ICD2. Dette firmware er utdatert og bør oppdateres. Det kan ikke bli oppdatert når aktiv. Men du kan fortsette å operere med dagens oppstart firmware hvis du velger å gjøre det. Vil du fortsette?
|
Hvis jeg trykker Ja her enn den prøver å koble til ICD2 selv, og fryses (Jeg har bare 4550 installert ennå).
Hvis jeg trykker NO enn den synes den prøver å oppdatere den, men vi trenger her en bootloader som dette, slik at denne meldingen vises:
| Code: |
ICD0288: Kan ikke re-programmet ICD2 USB Boot firmware.
ICD0021: Kan ikke koble til med MPLAB ICD 2
MPLAB ICD 2 Ready
|
Ok folkens, tror tror tror Hvordan kan vi bruke som bin å få jobbe bootloader i 4550!
Lagt etter 2 minutter:
Jeg har også utarbeidet prøven bootloader med riktig VID / PID men fikk samme resultat som med 4550.
Lagt til etter 16 minutter:
Det kan være at vi ikke kan få den første innledende første:) del av bootloader som laster den første bootloader som laster OS ...
Legges etter 5 minutter:
Dette er den tiden da rkodaira skal dumpe sine 4550 for 0 nivå bootloader. (med et stort håp om at ikke er beskyttet ...)
Rkodaira må du  |
|
| Tilbake til toppen | |
|
albert22
Registrert: 20. juli 2004
Innlegg: 95
Hjalp: 3
| | 03 april 2006 22:46 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | |
|
| Jeg har vært å analysere en utskrift som jeg har med meg av BL010101. og finne noen ting.
Det synes å godta 5 kommandoer som kommer enten fra PSP eller USART.
0x55 Execute koden starter på 0x0010.
0x56 Last hex (dette synes å ha mer subcommands)
0x5a sender data 0x01 0x01 0x03 (versjon av BL???)
To andre kommandoer bare slå på feil og Opptatt lysdioder og henger i en inffinite loop.
Følgende rutiner er relatert til det jeg kalt "Beregnigner hex" kommando:
I en annen rutine for BL sender følgende streng 0x5b "0810C9", 0x5d
Andre sender svar embeded i følgende streng 0x5b "0A000", U, 0x31, U, 0x5d. (der U synes å være 0x31, 0x34, 0x36 og 0x37).
Jeg gjorde ikke har mye tid til å fortsette med analyse. Jeg verken så USB overvåking som har blitt postet fordi Im på en cyberkrig. Men jeg tror disse dataene skal være pakket inn i USB-kommunikasjon |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 03 april 2006 23:30 Project erstatte CY7C64613 i ICD2 | | |
|
| Albert,
Jeg sjekket den serielle comm versus USB, USB bruker en wrapper gjennom den serielle ting.
Det synes den bruker EP1 for kontroll port (det er av og på) og EP2 som data port, bare i (ICD-> PC). |
|
| Tilbake til toppen | |
|
albert22
Registrert: 20. juli 2004
Innlegg: 95
Hjalp: 3
| | 05 april 2006 6:39 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | |
|
| Her er mine fremskritt med BL
Det var ingen slike subcommands. Belastningen hex kommandoen bare tar hex-poster, og skriver data til programmet minne 2 byte om gangen. Ser etter forskjellige feil inkludert rekke adresse. Ap. å unngå å gå inn i BL-programmet. Dette bekrefter at BL er allways bosatt på 877.
The [0A000 ", U, 0x31, U]. (2. U er første U 1) er usannsynlig å bli sett, fordi det er en feilrapport. Feil inkluderer: bad-format, checksum, dårlig adresseserien og EEPROM skrive feil .
Rutinen skal vente på 16 tegn starter med en 0x3c ('<') og slutter med en 0x3e ('>'). denne 16 tegn toppteksten inneholde adresse, lengde og kontrollsum for data som skal skrives i ASCII.
Hvis overskriften er korrekt Ap. den BL svar med "[0810C9]"
Dataene cames etter 0x7B
Dette formatet synes å være forskjellig fra en Intel hex format.
Zedman.
Kan du gjenkjente noe sånt i RS232
Morgendagens jeg vil være hjemme og kunne installere HDD å sjekke loggene og se om jeg kan være til hjelp. |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 05 april 2006 12:17 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | | tags: mplab protokollen icd2 icd2.dll icd2w2k.sys mplbcomm.dll |
|
| Jeg sitter fast med denne USB ting. Og jeg er trist.
Jeg forstår ikke helt vet hva de skal gjøre. Jeg tilbrakte mye tid på feilsøking i icd2.dll.
Problemet er: Jeg kan ikke sende enda en byte tilbake til MPLAB.
Jeg skal forklare hva jeg fant til nå, men ingen virkelig er interessert i (bare vil hente ferdig ting). (Unntak: albert, Kripton, rkodaira, Silvio og guttene i denne tråden)
Så MPLAB kommuniserer med ICD2 denne måten:
[MPLAB -> ICD2.dll -> MPLBCOMM.dll -> icd2w2k.sys ->] --- [ICD2 enhet]
Hvis du velger USB type forbindelse det vil be enheten beskrivelse fra ICD2 og sjekker for produktversjonen ord, hvis det 0x0003 enn det er en Cypress basert ICD2 hvis den 0x0010 enn det er en 4550 basert ett. Hvis 0x0010 funnet enn det sier det jeg har blitt postet før at OS i ICD2 må oppgraderes. Det er interessant at hvis versjon (0100) i filnavnet til OS.bin modifiseres til FFFF enn det hopper dette trinnet og kontrollerer bootloader versjonen. Her måtte jeg patch ICD2.dll å få det prøve å se BL.bin fil versjon også, det er hardkodet at selv den er satt til FFFF den wont forsøker å oppgradere, det er derfor jeg oppdatert den (sett hardkodet FFFF lavere) så nå sier hva jeg mentoined også før: det bl versjonen er for gammel, men det kan ikke oppgraderes, mens den er aktiv.
Ok. Jeg gjorde et lite prog fra eksempeldiagrammene bootloader, med riktig beskrivere og prøver å kommunisere med MPLAB for å dekryptere protokollen og å etterligne den BL i den nye 4550 ICD2.
ICD2 at Kripton bruker, (Cypress version) setter 7 OUT / IN endepunkter, men ifølge loggene det bruker bare EP1 for inn / ut og EP2 for IN. (UT betyr PC-> Enhet)
Det synes det sender USB bestemte kommandoer og data via EP1 ut, og tilbake på EP1 i, og sender bytes readed fra ICD2's 877 gjennom separate endepunktet EP2 i.
Når MPLAB prøver å sende th OS.bin å oppgradere fw os det sender et getUSBdescriptor kall til kjernen driver og sender ut et 0x12 bytes lang kommandoen ved hjelp DeviceIOControl kommandoen. Jeg debugged, den kommer med suksess i 4550.
Enn MPLAB utsteder en GetStatus samtale, og det synes fra samtalen parametere som det forventer 0x08 bytes av data tilbake.
Jeg satt opp min buffer med 8 byte, og angi eierskap til Sie. Men det har aldri sender at 8 byte tilbake (den ikke vises i USBMon). Bare vente.
Det kan være flere ting.
Kanskje jeg gjør st feil med oppsettet av 4550, men jeg prøvde den med en annen progs og det fungerer, kan sende bytes tilbake.
Jeg vet verten må sende og IN-kommando for å la enheten sende i hva det vil.
Men når jeg debugged MBLBCOMM, jeg så at DeviceIOControl command failed!
Jeg tought at kanskje noen etterretning var bygget inn i. Sys-filen, og den synker pakkestørrelsen fordi det er galt innholdet, men jeg tror det bør være et høyere nivå oppgave.
Når jeg kommer hjem vil jeg se Getlasterror verdi.
Noen har noen ide hvordan kan jeg se om det var en pakke som sendes ut, eller hvordan kan jeg fortsette? |
|
| Tilbake til toppen | |
|
Kripton2035
Registrert: 19. juli 2001
Innlegg: 482
Hjalp: 15
Bosted: Earth
| | 05 april 2006 16:59 Project erstatte CY7C64613 i ICD2 | | |
|
| kanskje bør du koble en 877 til PSP utgangen av 4550 for å se hva som kommer gjennom, og programmere 877 med bootloader vi? kan bytes du venter komme fra EP2 og så 877?
vil du at jeg skal sende en loggfil på en presis tilstand? av måten den er sikker på at du trenger en rokaida log med sin 4550 icd2 ..
PS: Jeg er ikke interessert i at prosjektet .. Jeg er bare nysgjerrig! Jeg har allerede en usb icd2! |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 05 april 2006 20:08 Project erstatte CY7C64613 i ICD2 | | |
|
| Takk Kripton,
Jeg skal gi deg beskjed når jeg trenger mer dump , Det er litt mer komplisert enn bare passerer gjennom bytes til 877 og tilbake, har det en protokoll wrapper på den.
Det du sa var veldig nyttig, men rkodeira wont sacrify hans splitter nye ICD2 ... Hvis han ville, enn med dump av det OS oppdateringen vil definere protokollen vel ... |
|
| Tilbake til toppen | |
|
Kripton2035
Registrert: 19. juli 2001
Innlegg: 482
Hjalp: 15
Bosted: Earth
| | 05 april 2006 22:09 Project erstatte CY7C64613 i ICD2 | | |
|
| | godt jeg ikke tror han må sacrify hans icd2! bare noen dumper med usbmon som jeg gjorde .. forhåpentligvis min icd2 er fremdeles arbeider! |
|
| Tilbake til toppen | |
|
albert22
Registrert: 20. juli 2004
Innlegg: 95
Hjalp: 3
| | 05 april 2006 22:16 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | | tags: icd2 Beregnigner hex kommandoen |
|
| Jeg kan ikke installere HHD skjerm for å se loggene fordi jeg bare har w98 hjemme.
Kan du eksporterer en dump av OS nedlasting til en. Txt, for meg?
-------
Hvordan CY tilbakestiller 877?
Det er et signal (pin 43) til undersiden av Q1 hvis Collector er MCLR. Men dette går til en kontakt som heter PROG. Jeg innser at dette signalet skal gå til 877 også.
Vi trenger å vite hvilke USB kommandoen tilbakestiller 877. Kanskje det er ett av kontroll endepunkter?
Jeg dont vite hva som er funksjonen til dette PROG kontakten. men ekstra endepunkter kan være knyttet til den.
----------
En av OS lastet til ICD2 synes å være: ICD01020405.hex Jeg har forsøkt å disassemby det, men jeg kan ikke få disassembler å erstatte hex-adresser med navnet på registre. Det vil ta lengre tid å finne ut hvordan det fungerer.
Et interessant faktum er at koden starter på 0x0010. Husk at BL samtaler denne adressen med utfører kommandoen.
Den BL versjon rapportert av mplab er 01.01.01.00 dette går ganske bra med BL-kommando som svar 01,01,01,03
---------
Det er ingen DPot (MCP41xxxx) i den brasilianske ICD. Hvordan sette Vpp?
Mesteparten av kloner har en fast Vpp. Betyr dette at den brasilianske ICD er bare en lav kostnad klone og ikke den nye ICD2? Jeg dont overveie det mikrobrikke gikk for en fast vpp. Hvis det er en annen metode for å kontrollere vpp, unntatt DPot ville trenge firmware endringer av ICD OS. Den gamle OS ville ikke fungere i det nye. Som kan være årsaken til at DLL er kontrollere versjonen. |
|
| Tilbake til toppen | |
|
Zedman
Registrert: 13. oktober 2003
Innlegg: 294
Hjalp: 2
| | 05 april 2006 22:32 Project erstatte CY7C64613 i ICD2 | | | tags: mplab protokollen icd2 icd2w2k.sys icd2w2k nedlasting 4550 bootloader skriver icd2w2k.sys nedlasting laste ned icd2w2k |
|
| Jeg tror ikke vi skal håndtere alt vedrørende krets eller protokollen eller forbindelsen mellom 877 og 4550 ennå. Jeg tror alt vi trenger, er skrevet i 4550 vinduer leveres med MPLAB.
Vi bør skrive en bootloader kompatibel med icd2w2k.sys å få OS.bin lastet ned, og etter at vi kan scracth hodene våre hvordan 877 er koblet til.
Legges etter 5 minutter:
I ICD2br bruker en annen type chip som genererer Vpp. Rkodaira mentoined, se innleggene før. |
|
| Tilbake til toppen | |
|
Silvio
Registrert: 31. desember 2001
Innlegg: 800
Hjalp: 90
| | 06 april 2006 2:36 Re: Prosjekt for å erstatte CY7C64613 i ICD2 | | | tags: icd2w2k.sys icd2w2k nedlasting 4550 bootloader skriver icd2w2k.sys nedlasting laste ned icd2w2k |
|
| | Zedman wrote: |
Vi bør skrive en bootloader kompatibel med icd2w2k.sys å få OS.bin nedlastet.
|
Ja, dette er den viktigste grunnen for som jeg sa at dissasembling CY fw den er ubrukelig så lenge vi har OS og BL bin filen leveres av Microchip. Slik starter koding fra grunnen av for 4550 og simulere CY fw ville være tidkrevende og verdiløs.
Som jeg setter pris zedman innsats.
Men noen ganger kan jeg ikke hjelpe meg til å spørre dette dumt spørsmål: Hvis BL ikke kan oppgraderes, mens den er aktiv, hva var Microchip's ICD2 designere tilnærming for oppgradering? Parallelt programmerer før lodding 4550? Eller gjennom ICSP med en ren bin bildet ned etter oppstart blokkere slettet?
Hvis rkodaira finner at CPB og EBTRB biter fjernes  , Så hvordan kan OS.bin lastes i 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 ? |
|
| Tilbake 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] |
|
| Tilbake 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. |
|
| Tilbake 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. |
|
| Tilbake 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 |
|
| Tilbake 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... |
|
| Tilbake 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. |
|
| Tilbake 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 (?) . |
|
| Tilbake 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. |
|
| Tilbake 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... |
|
| Tilbake 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. |
|
| Tilbake 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
|
|
|
| Tilbake til toppen | |
|
