| Autor | Missatge |
|---|
Kripton2035
Antiguitat: 19 de juliol 2001
Llocs: 482
Ajudar: 15
Ubicació: Terra
|  03 d'abril 2006 8:28 Re: Projecte per substituir CY7C64613 al ICD2 | | |
|
| | Predrag va escriure: | Els meus amics i no van tenir èxit en la programació ICD2_4550_BOOT_0180.BIN en 4550. I'v
va tractar d'obrir el fitxer bin winpic 800 amb el programari, però no. I tryed per obrir-lo amb l'opció "tots els fitxers" a "tipus de fitxer" perquè no hi ha suport directe als arxius bin. ICprog que tenen el suport (per obrir els arxius bin), però no pot programa 4550. De fet no hi ha cap llista dels dispositius a 4550. Què he de fer? Algun suggeriment? Jo només sóc un principiant però tinc bona voluntat per ajudar.
Perdó per la meva mala anglès. |
canviar el nom de l'. BIN a. HEX winpic i que s'obrirà!
a vegades una gran quantitat de fitxers. BIN intel lectual són en realitat. hexadecimal!
per estar segur, obrir l'arxiu amb el Bloc de notes, si conté línies que comencen amb ":" a continuació, canvieu el nom. hexadecimal i obert amb winpic .. si es tracta d'escombraries, després un bin2hex s'ha d'utilitzar per obrir-lo. |
|
| Tornar amunt | |
 |
narccizzo
Antiguitat: 20 de gener 2006
Llocs: 173
Ajudar a: 4
Ubicació: Pátzcuaro, Michoacán, MEXICO
| | 03 d'abril 2006 9:42 Re: Projecte per substituir CY7C64613 al ICD2 | | |
|
| Aquests són els dos arxius bin convertir en hexadecimal, he obert la caixa de fitxers amb el
ic-prog programari i guardar els arxius en format hexadecimal, si vostè dóna un cop d'ull a aquests fitxers es pot veure una cadena de lectura "Microxip ICD2 Tecnologia icd2 USB Dispositiu USB" a la direcció 0x0ee7 per l'arxiu i boot.hex la mateixa cadena al 0x0b8e per a la
os.hex arxiu, No tinc un desacoblar per explorar amb més detall aquests fitxers però alguna cosa em diu que aquests dos arxius són tot el que necessitem.
BR
Narccizzo
|
|
| Tornar amunt | |
|
Jay.slovak
Antiguitat: 23 de març 2006
Llocs: 11
| | 03 d'abril 2006 11:17 Re: Projecte per substituir CY7C64613 al ICD2 | | |
|
| | narccizzo va escriure: | Aquests són els dos arxius bin convertir en hexadecimal, he obert la caixa de fitxers amb el
ic-prog programari i guardar els arxius en format hexadecimal, si vostè dóna un cop d'ull a aquests fitxers es pot veure una cadena de lectura "Microxip ICD2 Tecnologia icd2 USB Dispositiu USB" a la direcció 0x0ee7 per l'arxiu i boot.hex la mateixa cadena al 0x0b8e per a la
os.hex arxiu, No tinc un desacoblar per explorar amb més detall aquests fitxers però alguna cosa em diu que aquests dos arxius són tot el que necessitem.
BR
Narccizzo |
Estàs segur que han convertit els arxius correctament? Si jo importació en MPLAB, el codi no té sentit, tot el que fa és només anar a través del Programa de memòria i fer PON. Res del útil que està succeint en els dos d'arrencada i SO HEXs. Fins i tot els bits de configuració són diferents en ambdós arxius! |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 03 d'abril 2006 11:19 de projecte per substituir CY7C64613 al ICD2 | | |
|
| Albert,
el nucli conductor (s) d'esperar, el xiprer es connectarà a un VINYA / PID quan firt connectat, i després que el carregador del sistema de descàrregues és FW es torni com un VINYA / PID de manera que el sistema d'altres parla amb ella. Hem d'aplicar només la segona.
@ Iam treball per la qual cosa no puc fer res aquí esperem dur pensant  ... |
|
| Tornar amunt | |
|
silvio
Antiguitat: 31 de desembre 2001
Llocs: 800
Ajudar: 90
| | 03 d'abril 2006 11:31 Re: Projecte per substituir CY7C64613 al ICD2 | | | Etiquetes: MPLAB protocol icd2 xiprer desacoblar desacoblar xiprer |
|
| Hola Zedman,
it's a must to understand what's under cover. Pel que fa a CY hexadecimal fitxer no és només una qüestió de bona desacoblar que coneix el xiprer de xip, però la lectura de 436 pàgines-USB EZ FX TechRefManual és una necessitat per comprendre el que està sota coberta.
I no crec que hi hagi temps per a això. Tanmateix, si vostè no està familiaritzat amb els opcodes 8051, en analitzar el codi va a prendre temps. (Sé que estàs familiaritzat amb els PIC)
with appropiate values from CY7C64613 registers 0x7800-0x7FFF but you'll definitely end up turning the pages of TechRefManual looking for definitions. No puc substituir tots els casos de MOV DPTR, # LXXXX amb els valors adequats de CY7C64613 registres 0x7800-0x7FFF però definitivament li acaben convertint les pàgines de TechRefManual buscant definicions.
A més de que alguns la dificultat d'assignar noms de bits que s'estableixen o clar en el programa, sempre que no s'assigna a l'espai SFR (que acaba en 0 o 8).
with MOV DPTR, #EP0CS but it's difficult to say SETB HSNAK due to the above reasons. És fàcil substituir MOV DPTR, # L7FB4 amb MOV DPTR, # EP0CS però és difícil dir SETB HSNAK degut a les raons anteriorment esmentades.
and EP0STAL L which are affected in the bellow code at 0x03E2. Prenguem l'exemple HSNAK bits i EP0STAL L que es veuen afectats en el codi de sota a 0x03E2.
| Codi: |
L03E2: LCALL L0FBE
Del JNC L03EE
MOV DPTR, # L7FB4
MOVX A, @ DPTR
ORL A, # 01h; algun tipus de SETB EP0STALL
MOVX @ DPTR, A
L03EE: MOV DPTR, # L7FB4
MOVX A, @ DPTR
ORL A, # 02h; algun tipus de SETB HSNAK
MOVX @ DPTR, A
RET
L0FBE: SETB C
RET
|
Prenguem, per exemple (CP_1.asm) les línies de codi a partir de compensar 0x0100 (una subrutines és anomenat des 0x05FA), la primera línia de codi utilitzat immediatelly avall taula de vectors d'interrupció
En RAM 0x7FE9 vostè pot trobar el 2n byte de 8 bytes de paquets de dades USB SETUP (vegeu la pàgina 215 table9-1), en el sentit de bRequest camp (vegeu el quadre 9-2).
| Codi: |
L0100: MOV DPTR, # L7FE9
MOVX A, @ DPTR
JNZ L0109
LJMP L029B, si bRequest = GetStatus saltar a 0x029B
L0109: DEC A
JNZ L010F
LJMP L0317; si bRequest = Esborrar Article, el salt a 0x0317
L010F: AFEGIR A, # 0FEh
JNZ L0116
LJMP L038E, si bRequest = Conjunt de característiques, el salt per 0x038E
L0116: AFEGIR A, # 0FBh
JNZ L011D
LJMP L0295; si bRequest = Obtenir configuració, salt a 0x0295
L011D: DEC A
JNZ L0123
LJMP L028F, si bRequest = Ajust de configuració, el salt per 0x028F
L0123: DEC A
JNZ L0129
LJMP L0283; si bRequest = Obtenir la interfície, el salt a 0x0283
L0129: DEC A
JNZ L012F
LJMP L0289; si bRequest = Conjunt d'interfície, el salt a 0x0289
L012F: AFEGIR A, # 05h
JZ L0136
LJMP L03E2; = bRequest si cap de les anteriors, a continuació, estableixi els bits HSNAK
i EP0STALL d'EP0CS control i registre d'estat i
i, a continuació, a 0x05FD RET
;
L0136: LCALL L0F7A; si bRequest = Obtenir Descriptor, on LCALL 0x0F7A
JC L013E; portar poc està configurat per defecte, per tal de saltar a 0x013E
LJMP L03EE; si al portar 0x0F7A seria 0 per defecte, fixat poc HSNAK
; EP0CS de control i registre d'estat i RET en 0x05FD
;
L013E: MOV DPTR, # L7FEB; aquí perquè era un bRequest Obtenir Descriptor
MOVX A, @ DPTR, per la qual cosa comprovar el camp de la WValueH USB SETUP paquet
AFEGIR A, # 0FEh
JZ L015F, si wValueH va ser 0x02 saltar a 0x015F
DEC A
JZ L0190; si wValueH va ser 0x03 salt a 0x0190
AFEGIR A, # 02h
JZ L0150; si wValueH va ser 0x01 salt a 0x0150
LJMP L0279; wValueh si és diferent de qualsevol de 0x01 o 0x02 o 0x03 després
; Bits HSNAK i EP0STALL de registre i EP0CS RET en 0x05FD
;
L0150: MOV A, 0Ch; aquí perquè wValueH va ser 0x01, de manera de càrrega USB SUDPTR registre mundial
MOV DPTR, # L7FD4; amb valor 0x0C0D, després poc HSNAK d'EP0CS i RET en 0x05FD
MOVX @ DPTR, A
MOV A, 0DH
MOV DPTR, # L7FD5
MOVX @ DPTR, A
LJMP L03EE
L015F: MOV DPTR, # L7FEA; mirada ara en l'àmbit de la wValueL USB SETUP paquet
;
;
;
;
, Etc ...................
|
port2: Microchip MPLAB ICD2 Fw client Aquesta taula de cerca o en el desplaçament 0x0622 que coincideixin amb el Kripton2035 port2: Microchip MPLAB ICD2 Fw client
| Codi: |
Taula 5-9. Dispositiu USB predeterminat Descriptor
Valor de compensació de RAM Camp Descripció
0622 0x12 blength 0 Longitud de la present Descriptor = 18 bytes
0623 0x01 1 bDescriptorType Descriptor = Tipus de dispositiu
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 és específica del proveïdor)
0627 0xFF 5 bDeviceSubClass Sub-classe de dispositius (FF és específica del proveïdor)
0628 0xFF Dispositiu 6 bDeviceProtocol Protocol (FF és específica del proveïdor)
0629 0x40 7 bMaxPacketSize0 Tamany màxim de paquet de 64 bytes = EP0
062A 0xD8 8 idVendor (L) Identificació de proveïdors (L) = 04D8H Microxip Tecnologia
062B 0x04 9 idVendor (H) Identificació de proveïdors (H)
062C 0x01 10 idProduct (L), Identificador del producte (L) ICD2 = 8001H
062D 0x80 11 idProduct (H) Identificador del producte (H)
062E 0x03 12 bcdDevice (L) Nombre de dispositius de llançament (BCD, L)
062F 0x00 13 bcdDevice (H) Nombre de dispositius de llançament (BCD, H)
0630 0x00 14 iManufacturer Fabricant Índex String = Cap
0631 0x00 15 iProduct Product Index String = Cap
0632 0x00 16 iSerialNumber número de sèrie de l'Índex String = Cap
0633 0x01 17 bNumConfigurations Número de Configuracions en aquesta interfície = 1
Taula 5-10. USB configuració predeterminada Descriptor
Valor de compensació de RAM Camp Descripció
0634 0x09 blength 0 Longitud de la present Descriptor = 9 bytes
0635 0x02 1 bDescriptorType Descriptor = Tipus de configuració
0636 0x74 2 wTotalLength (L) Longitud total (L) Inclou la interfície i punt final Descriptors = 116
0637 0x00 3 wTotalLength (H) Longitud total (H)
0638 0x01 4 Nombre de Interfícies bNumInterfaces en aquesta configuració
0639 0x01 5 bConfigurationValue configuració valor utilitzat per Set_Configuration Seleccioneu aquesta Sol.licitud de configuració
063A 0x00 6 iConfiguration Índex de String descriu aquesta configuració = Cap
063B 0x80 7 bmAttributes Atributs - Bus-Powered, no de despertador
063C 0x4B 8 MaxPower Potència màxima - 150 mA
Taula 5-11. Interfície USB predeterminat 0, Suplent Configuració 0 Descriptor
Valor de compensació de RAM Camp Descripció
063D 0x09 blength 0 Longitud de la interfície Descriptor
063E 0x04 1 bDescriptorType Descriptor = Tipus d'interfície
063F 0x00 2 bInterfaceNumber Índex de base zero d'aquesta interfície = 0
0640 0x00 3 bAlternateSetting altre Ajust Valor = 0
0641 0x0E 4 bNumEndpoints Número de punts finals en aquesta interfície (sense comptar OEP) = 14
0642 0xFF 5 bInterfaceClass = Interfície de la classe de proveïdors específics
0643 0xFF 6 bInterfaceSubClass Interfície Sub-class = Vendor Specific
0644 0xFF 7 bInterfaceProtocol = Interfície de Protocol de proveïdors específics
0645 0x00 8 Índex de la Cadena iInterface Descriptor per aquest Interface = Cap
Taula 5.-14.. Interfície per defecte 0, Suplent Configuració 1, punt final a granel Descriptors
Valor de compensació de RAM Camp Descripció
0646 0x07 0 Longitud blength d'aquest paràmetre Descriptor
0647 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0648 0x01 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT1
0649 0x02 3 bmAttributes XFR = Tipus A GRANEL
064A 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
064B 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
064C 0x01 6 bInterval interval de sondeig en milisegons
064D 0x07 Longitud 0 blength d'aquest paràmetre Descriptor
064E 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
064F 0x02 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT2
0650 0x02 3 bmAttributes XFR = Tipus A GRANEL
0651 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0652 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0653 0x01 6 bInterval interval de sondeig en milisegons
0654 0x07 0 Longitud blength d'aquest paràmetre Descriptor
0655 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0656 0x03 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT3
0657 0x02 3 bmAttributes XFR = Tipus A GRANEL
0658 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0659 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
065A 0x01 6 bInterval interval de sondeig en milisegons
065B 0x07 Longitud 0 blength d'aquest paràmetre Descriptor
065C 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
065D 0x04 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT4
065E 0x02 3 bmAttributes XFR = Tipus A GRANEL
065F 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0660 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0661 0x01 6 bInterval interval de sondeig en milisegons
0662 0x07 0 Longitud blength d'aquest paràmetre Descriptor
0663 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0664 0x05 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT5
0665 0x02 3 bmAttributes XFR = Tipus A GRANEL
0666 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0667 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0668 0x01 6 bInterval interval de sondeig en milisegons
0669 0x07 0 Longitud blength d'aquest paràmetre Descriptor
066A 0x05 1 bDescriptor Tipus Tipus Descriptor = Punt final
066B 0x06 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT6
066C 0x02 3 bmAttributes XFR = Tipus A GRANEL
066D 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
066E 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
066F 0x01 6 bInterval interval de sondeig en milisegons
0670 0x07 blength Longitud 0 aquest paràmetre Descriptor
0671 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0672 0x07 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = OUT7
0673 0x02 3 bmAttributes XFR = Tipus A GRANEL
0674 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0675 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0676 0x01 6 bInterval interval de sondeig en milisegons
Valor de compensació de RAM Camp Descripció
0677 0x07 0 Longitud blength d'aquest paràmetre Descriptor
0678 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0679 0x81 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = IN1
067A 0x02 3 bmAttributes XFR = Tipus A GRANEL
067B 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
067C 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
067D 0x01 6 bInterval interval de sondeig en milisegons
067E 0x07 Longitud 0 blength d'aquest paràmetre Descriptor
067F 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0680 0x82 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = IN2
0681 0x02 3 bmAttributes XFR = Tipus A GRANEL
0682 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0683 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0684 0x01 6 bInterval interval de sondeig en milisegons
0685 0x07 0 Longitud blength d'aquest paràmetre Descriptor
0686 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0687 0x83 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = IN3
0688 0x02 3 bmAttributes XFR = Tipus A GRANEL
0689 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
068A 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
068B 0x01 6 bInterval interval de sondeig en milisegons
068C 0x07 Longitud 0 blength d'aquest paràmetre Descriptor
068D 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
068E 0x84 2 bEndpointAddress extrems Direcció (1 s) i direcció IN4 =
068F 0x02 3 bmAttributes XFR = Tipus A GRANEL
0690 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0691 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0692 0x01 6 bInterval interval de sondeig en milisegons
0693 0x07 0 Longitud blength d'aquest paràmetre Descriptor
0694 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
0695 0x85 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = IN5
0696 0x02 3 bmAttributes XFR = Tipus A GRANEL
0697 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
0698 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
0699 0x01 6 bInterval interval de sondeig en milisegons
069A 0x07 blength Longitud 0 aquest paràmetre Descriptor
069B 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
069C 0x86 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = IN6
069D 0x02 3 bmAttributes XFR = Tipus A GRANEL
069E 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
069F 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
06A0 0x01 6 bInterval interval de sondeig en milisegons
06A1 0x07 Longitud 0 blength d'aquest paràmetre Descriptor
06A2 0x05 1 bDescriptor Descriptor Tipus Tipus = Punt final
06A3 0x87 2 bEndpointAddress Direcció Punt final (1 a) i Direcció = IN7
06A4 0x02 3 bmAttributes XFR = Tipus A GRANEL
06A5 0x40 4 wMaxPacketSize (L) Tamany màxim de paquet = 64 Bytes
06A6 0x00 5 wMaxPacketSize (H) Tamany màxim de paquet - Alt
06A7 0x01 6 bInterval interval de sondeig en milisegons
que és seguit per Unicode forma de cadena que va acabar zero
"Tecnologia de Microxip ICD2 USB Device"
|
Tanmateix, si et quedes encallat amb bin 4550, puc mirar d'ajudar mitjançant l'addició de comentaris a l'arxiu asm CY. |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 03 d'abril 2006 17:10 Re: Projecte per substituir CY7C64613 al ICD2 | | | Etiquetes: icd2.dll |
|
| Hola Silvio,
gràcies per la informació, molt temps enrera he hagut d'analitzar un arxiu bin procedents d'un xip EPROM. Ni tan sols el tipus de processador no es ni el circuit. Però jo havia de trobar la forma en que es tracta d'una targeta de memòria, i les seves dades.
Jo donava per suposat que és una espècie de xip de 8051 i va tractar d'disassemblers molt, i va acabar amb un 80C542 (i cant recordar que va ser precisament un) Jo pense que a partir dels números de port i la forma en que el codi s'ocupa dels pins del port.
No obstant això, va prendre 2 setmanes de treball de dia i de nit  per a mi, molt de la lectura / depuració / aprenentatge.
Per això jo volia un assemblador el que és capaç de fer les coses que es menciona en lloc amb mi ... 
Gràcies de nou Silvio.
-----------------------------
Iam començant a creure que tots, d'acord amb bin. Vaig fer una recerca en ICD2 dll i va descobrir que les trucades GETUSBDESCRIPTOR i números dels controls en el descriptor i si coincideix amb la versió més recent ICD2 que vaig signar en el meu Descriptor de 4550 del que fa una crida send4550image!
I també hi ha descriptors d'arxius a la paperera idèntica a la que Kripton carregat.
Una cosa que no entenc és per què van enviar a la imatge d'arrencada?
I per què ICD2.dll Intenta descarregar aquest arxiu? Si jo arribi a casa, vaig a tractar de definir el meu descriptors per tal que coincideixi amb el que vaig trobar a la caixa i tractarà MPLAB en ell.
Crec que s'estan acostant! 
Creat després de 46 minuts:
I hi ha una cosa de màgia a la primera arrencada de la btyes bin: MCHP (microxip?)
He buscat per ell, si és més tard (després de la càrrega) reemplaça aquests amb Goto veritable punt d'entrada o primera, però en el ICD2.dll no.
Creat després de 3 hores 34 minuts:
Mira això:
Vaig fer el que he dit abans, acaba d'establir el número de versió a la més nova i que espera MPLAB tracta d'enviar el sistema operatiu! (Per suposat que la meva FW no és un gestor d'arrencada)
| Codi: |
MPLAB ICD 2 Llest
Connexió a MPLAB ICD 2
ICD0289: No es pot tornar a programa ICD2 USB OS microprogramari.
ICD0021: No es pot connectar amb MPLAB ICD 2
MPLAB ICD 2 Llest
|
D'alguna manera el carregador hauria de treballar, vaig a tractar de fer alguna cosa per la nit. |
|
| Tornar amunt | |
|
narccizzo
Antiguitat: 20 de gener 2006
Llocs: 173
Ajudar a: 4
Ubicació: Pátzcuaro, Michoacán, MEXICO
| | 03 d'abril 2006 18:43 de projecte per substituir CY7C64613 al ICD2 | | |
|
| Hola JaySlovak
No, Im no està segur, només em va obrir la caixa i deseu-lo en format hexadecimal.  |
|
| Tornar amunt | |
|
Jay.slovak
Antiguitat: 23 de març 2006
Llocs: 11
| | 03 d'abril 2006 20:45 Re: Projecte per substituir CY7C64613 al ICD2 | | |
|
| | narccizzo va escriure: | Hola JaySlovak
No, Im no està segur, només em va obrir la caixa i deseu-lo en format hexadecimal. |
Sí, és extrany que la cadena és llegible, només el codi no fa res |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 03 d'abril 2006 22:25 Re: Projecte per substituir CY7C64613 al ICD2 | | | Etiquetes: icd2.dll |
|
| Bones notícies, després de 2 hores de depuració,
ICD2.dll fa ús tant de bin. L'arxiu de sistema operatiu vol ser descarregats només a ICD2s nou producte amb número de sèrie.
PERÒ quan es modifiqui l'ID de la versió en el nom de l'arxiu de OS.bin * _FFFF.bin perquè comenci a comprovar la versió d'arrencada cercar:
| Codi: |
Connexió a MPLAB ICD 2
ICDWarn0062: L'USB d'arrencada del firmware de la ICD2 és activa i la prestació de les comunicacions amb el ICD2. Aquest firmware és obsoleta i s'ha d'actualitzar. No pot ser actualitzat al mateix temps actiu. Tanmateix, pot seguir funcionant amb el firmware actual d'arrencada, si decideix fer-ho. Voleu continuar?
|
Si jo premeu YES aquí del que intenta connectar-se a ICD2 si mateix, i es bloqueja (només he instal lat encara el 4550).
Si jo premeu NO del que sembla que intenta actualitzar, però que necessitem un carregador d'aquest tipus, pel que aquest missatge apareix:
| Codi: |
ICD0288: No es pot tornar a programa ICD2 USB d'arrencada de microprogramari.
ICD0021: No es pot connectar amb MPLAB ICD 2
MPLAB ICD 2 Llest
|
Bé nois, pensar pensar pensar com podem utilitzar aquest bin per obtenir un treball de gestor d'arrencada en un 4550!
Creat després de 2 minuts:
També va compilar la mostra amb el carregador correcte VINYA / PID, però té els mateixos resultats que amb el meu 4550.
Creat després de 16 minuts:
Pot ser, que no podem obtenir la primera inicial inicial:) part del carregador que carrega el primer carregador d'arrencada que carrega el sistema operatiu ...
Creat després de 5 minuts:
Aquest és el moment en què rkodaira ha bolcar el seu 4550 per al nivell 0 d'arrencada. (amb una gran esperança de que no està protegit ...)
Rkodaira Et necessitem  |
|
| Tornar amunt | |
|
albert22
Antiguitat: 20 de juliol 2004
Llocs: 95
Ajudat: 3
| | 03 d'abril 2006 22:46 Re: Projecte per substituir CY7C64613 al ICD2 | | |
|
| He estat l'anàlisi d'una impressió que tinc amb mi de la BL010101. i trobar algunes coses.
Sembla acceptar comandes propers 5 a partir de la PSP o el USART.
0x55 executar codi a partir de 0x0010.
0x56 Càrrega hexadecimal (això sembla haver una major subcommands)
0x5a envia les dades 0x01 0x01 0x03 (Versió de la BL?)
Altres dos comandaments al seu torn en l'error i ocupat Leds i penja en un bucle inffinite.
Les següents rutines estan relacionades amb el que he anomenat la "càrrega hexadecimal" comanda:
En una altra rutina la BL envia la següent sèrie de caràcters 0x5b ", 0810C9", 0x5d
Altres respostes envia embeguda en la següent sèrie de caràcters 0x5b, "0A000", U, 0x31, U, 0x5d. (on U sembla ser 0x31, 0x34, 0x36 i 0x37).
I didnt tenen molt de temps per continuar amb l'anàlisi. Jo no vaig veure USB vigilància que han estat enviats ja Im que en un cyber. Però crec que aquestes dades han de ser embalats en la comunicació USB |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 03 d'abril 2006 23:30 de projecte per substituir CY7C64613 al ICD2 | | |
|
| Albert,
Ho vaig comprovar la sèrie front a la comunicació USB, USB utilitza un embolcall a través de la sèrie cosa.
Sembla que utilitza EP1 de port de control (és OUT i IN) i EP2 com a port de dades, només en (CIE-> pc). |
|
| Tornar amunt | |
|
albert22
Antiguitat: 20 de juliol 2004
Llocs: 95
Ajudat: 3
| | 05 d'abril 2006 6:39 Re: Projecte per substituir CY7C64613 al ICD2 | | |
|
| Aquí estan els meus avenços amb la BL
No hi va haver tal subcommands. La càrrega hexadecimal només pren el comandament hexagonal registres i escriu les dades a la memòria del programa de 2 bytes a la vegada. Comprova per a diferents errors com la gamma de la direcció. Ap per evitar la intensificació en el programa d'BL. Això confirma que la BL és sempre resident a la 877.
L'[0A000 ", U, 0x31, U]. (La 2 ª U és la primera U 1) és poc probable que sigui vist, perquè és un informe d'errors. Els errors són: malformats, de verificació, la mala direcció i el rang d'error de escriptura EEPROM .
La rutina espera a 16 caràcters a partir d'una 0x3c ('<') i acabant amb un 0x3e ('>'). aquesta capçalera de 16 caràcters de contenir l'adreça, longitud i de comprovació de les dades a ser escrits en ASCII.
Si és correcta la capçalera Ap respostes amb la BL "[0810C9]"
Les dades acompanya després d'un 0x7B
Aquest format sembla ser diferent d'un intel lectual hexadecimal.
Zedman.
Pot ser que vostè reconeix alguna cosa com això en el RS232
Demà serà a casa meva i poder instal lar hdd per comprovar els registres i veure si pot ser de cap ajut. |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 05 d'abril 2006 12:17 Re: Projecte per substituir CY7C64613 al ICD2 | | | Etiquetes: MPLAB protocol icd2 icd2.dll icd2w2k.sys mplbcomm.dll |
|
| Estic enganxat amb aquesta cosa USB. I estic trist.
En realitat no sé què fer. Vaig passar molt de temps a la depuració icd2.dll.
El problema és: No puc enviar un byte, fins i tot tornar a MPLAB.
Vaig a explicar el que he trobat fins ara, encara que no realment interessat en un (només volen agafar acabat cosa). (Excepte: albert, Kripton, rkodaira, Silvio, i els nois en aquest fil)
Per tant, es comunica amb el MPLAB ICD2 d'aquesta manera:
[MPLAB -> ICD2.dll -> MPLBCOMM.dll -> icd2w2k.sys ->] --- [ICD2 dispositiu]
Si vostè selecciona el tipus de connexió USB li demanarà el dispositiu de la Descriptor ICD2 i comprova la versió del producte paraula, si és 0x0003 que es tracta d'un xiprer ICD2 basat, si és 0x0010 que és una basada en un 4550. 0x0010 va trobar que si es diu el que he estat enviat abans que el sistema operatiu en el ICD2 ha de ser actualitzat. És interessant que si la versió (0100) en el nom de l'arxiu de la OS.bin FFFF s'ha modificat per a que el que se salta aquest pas i es comprova la versió d'arrencada. Aquí vaig haver de ICD2.dll pedaç per tractar de comprovar la versió de l'arxiu BL.bin massa, és que fins i tot hardcoded és ajustat a FFFF no ho puc tractar de millorar, per això és pedaç (hardcoded conjunt FFFF a menor) per la qual cosa ara diu el que jo també abans de mentoined: bl la versió és massa antiga, però no es pot actualitzar mentre que l'activa.
Bé. Vaig fer un petit progrés de la mostra d'arrencada, amb els descriptors de corregir i tractar de comunicar-se amb MPLAB per tal de desxifrar el protocol i per a emular el BL en el nou 4550 ICD2.
ICD2 que Kripton usos, (versió xiprer) estableix 7 / EN extrems, però d'acord amb els registres que fa servir només per EP1 IN / OUT i EP2 d'EN. (FORA mitjà de PC-> Dispositiu)
Sembla que envia el usb comandaments específics i dades a través de EP1, i de nou en el EP1, i envia els bytes de la ICD2 llegida 877 a través de la variable independent EP2 polz
Quan intenta enviar MPLAB º OS.bin per millorar el FW us emet una crida a getUSBdescriptor el nucli conductor, i envia una comanda 0x12 bytes de longitud utilitzant DeviceIoControl comanda. I depurat, que arriba amb èxit a la 4550.
MPLAB qüestions que GetStatus una trucada, i sembla que els paràmetres de la trucada que espera 0x08 bytes de dades de tornada.
Vaig posar la meva tampó amb 8 bytes, i establir la propietat a SIE. Però mai que envia 8 bytes enrera (que no apareix en USBMon). Només espera.
No hi pot haver moltes coses.
Potser faig malament a la primera configuració de 4550, però he intentat amb una altra progs i funciona, pot enviar a octet esquena.
Sé que l'amfitrió ha d'enviar a la comanda i el dispositiu per a que envieu en el que vol.
Però quan depurat MBLBCOMM, vaig veure que el comandament no DeviceIoControl!
I tought intel ligència que potser alguns es va construir al. Sistema d'arxiu i es descarta el paquet, ja que està malament el contingut, però crec que hauria de ser una tasca de nivell superior.
Quan arribi a casa vaig a comprovar el valor de GetLastError.
Algú té alguna idea de com puc veure si hi ha algun paquet enviat a, o com puc exercir? |
|
| Tornar amunt | |
|
Kripton2035
Antiguitat: 19 de juliol 2001
Llocs: 482
Ajudar: 15
Ubicació: Terra
| | 05 d'abril 2006 16:59 de projecte per substituir CY7C64613 al ICD2 | | |
|
| pot ser que vostè ha de connectar el 877 a un port de la PSP 4550 per veure el que ve a través de, i el programa 877 amb el gestor d'arrencada que tenim? pot ser l'esdeveniment que espera a octet procedeixen de la EP2, per la qual cosa el 877?
Vols que enviar un altre fitxer de registre d'una condició necessària? per la forma en que l'assegurança que necessita un rokaida registre de 4550 amb el seu icd2 ..
PS: No estic interessat en aquest projecte .. Sóc només curiositat! Ja tinc una usb icd2! |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 05 d'abril 2006 20:08 de projecte per substituir CY7C64613 al ICD2 | | |
|
| Gràcies Kripton,
Jo us avisi quan necessita més bolcat , És una mica més complexa del que acaba de passar pels bytes a 877 i de tornada, té un protocol en el mateix embolcall.
El que vostè diu és molt útil, però rkodeira costum sacrify seu nou ICD2 ... Si ell, que amb el bolcat del seu procés d'actualització de sistema operatiu es podria definir el protocol de ... |
|
| Tornar amunt | |
|
Kripton2035
Antiguitat: 19 de juliol 2001
Llocs: 482
Ajudar: 15
Ubicació: Terra
| | 05 d'abril 2006 22:09 de projecte per substituir CY7C64613 al ICD2 | | |
|
| | No penso així que necessita per sacrify seu icd2! només alguns abocadors amb usbmon com jo ho vaig fer .. tant de bo el meu icd2 segueix treballant! |
|
| Tornar amunt | |
|
albert22
Antiguitat: 20 de juliol 2004
Llocs: 95
Ajudat: 3
| | 05 d'abril 2006 22:16 Re: Projecte per substituir CY7C64613 al ICD2 | | | Etiquetes: icd2 hexadecimal comanda de càrrega |
|
| No puc instal lar HHD monitor per veure els registres, perquè només tinc W98 a casa.
¿Es pot exportar un bolcat del sistema operatiu per a descarregar un arxiu. Txt, per a mi?
-------
Com la CIA restableix el 877?
Hi ha un senyal (patilla 43) a la base de Q1 que el col lector és MCLR. Però això va a un connector anomenat PROG. Ara s'adonen que aquest senyal ha d'anar a la 877 també.
Hauríem de saber què USB comanda restableix el 877. Pot ser el que és una de les variables de control?
No sé quina és la funció d'aquest connector PROG. però els criteris de valoració addicional pot estar relacionat amb ella.
----------
Un carregar el sistema operatiu a la ICD2 sembla ser: ICD01020405.hex he intentat disassemby, però no puc obtenir el desacoblar per substituir la hexagonal d'adreces amb el nom dels registres. Es tindrà més temps per esbrinar com funciona.
Un fet interessant és que el codi comença a 0x0010. Recordi que el BL crida a aquesta adreça amb la comanda executar.
BL va informar la versió de MPLAB és 01.01.01.00 aquest va força bé amb la comanda que BL respostes 01,01,01,03
---------
No hi ha DPot (MCP41xxxx) brasiler en el CIE. Com establir VPP?
La majoria dels clons tenen un VPP. ¿Això significa que el brasiler CIE no és més que una de baix cost i no el clon nou ICD2? No penso que va ser per un microxip fix VPP. Si no hi ha altre mètode de control de la VPP, diferent de la DPot hauria canvis de firmware de la CIE OS. El vell sistema operatiu no funcioni en el nou. Que pot ser la causa que el fitxer DLL està comprovant la versió. |
|
| Tornar amunt | |
|
Zedman
Antiguitat: 13 d'octubre 2003
Llocs: 294
Ajudat: 2
| | 05 d'abril 2006 22:32 de projecte per substituir CY7C64613 al ICD2 | | | Etiquetes: MPLAB protocol icd2 icd2w2k.sys icd2w2k descarregar 4550 carregador escriure icd2w2k.sys download descarregar icd2w2k |
|
| No crec que hauria d'ocupar-se de res en relació amb el protocol o circuit o connexió entre 877 i 4.550 encara. Crec que tot el que necessitem està escrit en el 4550 es subministra amb MPLAB papereres.
Hem d'escriure un carregador compatible amb el icd2w2k.sys per obtenir el OS.bin descarregat, i després que puguem scracth cap la forma en que el 877 està connectat.
Creat després de 5 minuts:
En ICD2br utilitza un altre tipus de xip que genera el VPP. Rkodaira mentoined, comproveu abans dels llocs. |
|
| Tornar amunt | |
|
silvio
Antiguitat: 31 de desembre 2001
Llocs: 800
Ajudar: 90
| | 06 d'abril 2006 2:36 Re: Projecte per substituir CY7C64613 al ICD2 | | | tags: icd2w2k.sys icd2w2k download 4550 bootloader write icd2w2k.sys download download icd2w2k |
|
| | Zedman wrote: |
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 ? |
|
| Back to top | |
|
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] |
|
| Back to top | |
|
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. |
|
| Back to top | |
|
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. |
|
| Back to top | |
|
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 |
|
| Back to top | |
|
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... |
|
| Back to top | |
|
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. |
|
| Back to top | |
|
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 (?) . |
|
| Back to top | |
|
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. |
|
| Back to top | |
|
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... |
|
| Back to top | |
|
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. |
|
| Back to top | |
|
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
|
|
|
| Back to top | |
|
