From: N_Cook on 20 May 2010 09:17 Franc Zabkar <fzabkar(a)iinternode.on.net> wrote in message news:v16au55l7efkpp3s4891vs52e84invl93a(a)4ax.com... > On Wed, 5 May 2010 08:56:58 +0100, "N_Cook" <diverse(a)tcp.co.uk> put > finger to keyboard and composed: > > >that 1K5 will have to go back in , It is the first point of recognition for > >USB linking. Next to find why DISCON is permanently H. > > My understanding is that the pullup resistor on D+ signals to the host > (your PC) that a USB device has been plugged in. The host then > attempts to enumerate (ie identify) the device. > > If the device takes too long to go through its POST and initialisation > routines, then the host may time out. In such cases the device may > implement an active pullup which is disabled during its POST. When the > device is ready, the pullup resistor is enabled, allowing enumeration > to begin. > > AIUI, the normal state of DISCON# is high. > > See this EZ-USB Development Board (circuit on pages 5 & 6): > http://www.minford.ca/MF3001EZUSBManual.pdf > > I found this detailed document: > > The EZ-USB USB Integrated Circuit Technical Reference: > http://www.digchip.com/data/115/115-00027-0-AN2121S.pdf > > It states that EZ-USB devices can power up in RAM-only mode, in which > case the host downloads runtime code into the 8051 CPU's internal 8K > RAM. During this time the device identifies itself as a "Default USB > Device". After the code has been downloaded, the device disconnects > and then reconnects, this time renumerating as the device defined > within the downloaded code. > > Page 41 describes the EA (external access) pin. I think this may be > the key to how the device behaves. The tech ref also talks about mask > ROMed versions. Perhaps there is a way to force the EZ-USB chip into > RAM-only mode??? If so, then this will remove any corrupt firmware > from the equation. You could then use UVCView to see how the device > enumerates under these circumstances. > > You could also disconnect the serial EEPROM, if any. The EEPROM would > contain Product and Vendor IDs for the manufacturer of the mixer. If > the EEPROM is absent, then the EZ-USB chip will ID with the PID and > VID of 0x0547 (Cypress Semiconductor) and 0x2131 (EZ-USB), > respectively. > > - Franc Zabkar > -- > Please remove one 'i' from my address when replying by email. I got back to this today. Saved to disc the existing (corrupted ?) data in the serial EEPROM and cut the SDA line to the Ez-usb chip. The EZbus mixer is no longer "Becoming Ezbus" and a blank screen. But windows recognises a USB device connected and by UVCView/USB view the USB is working up to the USB chip , reading ---===>Device Information<===--- ConnectionStatus: Current Config Value: 0x00 -> Device Bus Speed: Full Device Address: 0x00 Open Pipes: 0 *!*ERROR: No open pipes! ===>Device Descriptor<=== bLength: 0x12 bDescriptorType: 0x01 bcdUSB: 0x0100 bDeviceClass: 0xFF -> This is a Vendor Specific Device bDeviceSubClass: 0xFF bDeviceProtocol: 0xFF bMaxPacketSize0: 0x40 = (64) Bytes idVendor: 0x0547idProduct: 0x2131 bcdDevice: 0x0004 iManufacturer: 0x00 iProduct: 0x00 iSerialNumber: 0x00 bNumConfigurations: 0x01 ie Cypress VID/PID Where to now? presumably forcing a pipe somehow
From: N_Cook on 21 May 2010 03:21 I'm thinking out in wwwland must be some general Cypress utility for transfering minimal data into their chippery to redesignate VID/PID pipe/endpoints etc. Put a switch in the SDA line , leave open at power up , so USB designated Cypress, then after 3 seconds when clock line is high close the switch. Then upload something to the memory, enough to redisignate the USB identity. Then power down and power up and transfer the mixer firmware.
From: N_Cook on 21 May 2010 06:23 Anyone familiar with this sort of utility EZ Loader Custom USB Firmware Loader Driver http://www.cypress.com/?docID=4503 just to rejig USB ident to then use the firmware transfer for the particular application ? here a digital mixer that is otherwise dead from corrupted firmware transfer. eg p4 " 8. Before you can use your new firmware driver you will need to bind it with your device. This is done by loading the serial EEPROM with the VID/PID combination defined in the INF file you create for your custom USB device. This is the first of two VID/PID combinations your device will use. When the VID/PID in the EEPROM is reported to the host, the host will invoke the wdgtldr.sys which loads your firmware. To load your VID/PID combination in the serial EEPROM open the EZ-USB Control Panel, ensure the Target Field matches your target device, and download the Vend_ax.hex example. "
From: Franc Zabkar on 21 May 2010 18:51 On Thu, 20 May 2010 14:17:20 +0100, "N_Cook" <diverse(a)tcp.co.uk> put finger to keyboard and composed: >I got back to this today. Saved to disc the existing (corrupted ?) data in >the serial EEPROM and cut the SDA line to the Ez-usb chip. >The EZbus mixer is no longer "Becoming Ezbus" and a blank screen. >But windows recognises a USB device connected and by UVCView/USB view the >USB is working up to the USB chip , reading > > ---===>Device Information<===--- > >ConnectionStatus: >Current Config Value: 0x00 -> Device Bus Speed: Full >Device Address: 0x00 >Open Pipes: 0 >*!*ERROR: No open pipes! > > ===>Device Descriptor<=== >bLength: 0x12 >bDescriptorType: 0x01 >bcdUSB: 0x0100 >bDeviceClass: 0xFF -> This is a Vendor Specific Device >bDeviceSubClass: 0xFF >bDeviceProtocol: 0xFF >bMaxPacketSize0: 0x40 = (64) Bytes >idVendor: 0x0547idProduct: >0x2131 >bcdDevice: 0x0004 >iManufacturer: 0x00 >iProduct: 0x00 >iSerialNumber: 0x00 >bNumConfigurations: 0x01 > >ie Cypress VID/PID > >Where to now? presumably forcing a pipe somehow You already know more about USB than I do. :-) However, I wonder if the data in the serial EEPROM are checksummed, in which case it may be possible to confirm its integrity. ISTM that you've at least confirmed that the EZ-USB chip has sanity, if you weren't already convinced by your scope tests. - Franc Zabkar -- Please remove one 'i' from my address when replying by email.
From: N_Cook on 22 May 2010 02:49 Franc Zabkar <fzabkar(a)iinternode.on.net> wrote in message news:783ev5dk9104rgolcskn3hh300s4bn1ie8(a)4ax.com... > On Thu, 20 May 2010 14:17:20 +0100, "N_Cook" <diverse(a)tcp.co.uk> put > finger to keyboard and composed: > > >I got back to this today. Saved to disc the existing (corrupted ?) data in > >the serial EEPROM and cut the SDA line to the Ez-usb chip. > >The EZbus mixer is no longer "Becoming Ezbus" and a blank screen. > >But windows recognises a USB device connected and by UVCView/USB view the > >USB is working up to the USB chip , reading > > > > ---===>Device Information<===--- > > > >ConnectionStatus: > >Current Config Value: 0x00 -> Device Bus Speed: Full > >Device Address: 0x00 > >Open Pipes: 0 > >*!*ERROR: No open pipes! > > > > ===>Device Descriptor<=== > >bLength: 0x12 > >bDescriptorType: 0x01 > >bcdUSB: 0x0100 > >bDeviceClass: 0xFF -> This is a Vendor Specific Device > >bDeviceSubClass: 0xFF > >bDeviceProtocol: 0xFF > >bMaxPacketSize0: 0x40 = (64) Bytes > >idVendor: 0x0547idProduct: > >0x2131 > >bcdDevice: 0x0004 > >iManufacturer: 0x00 > >iProduct: 0x00 > >iSerialNumber: 0x00 > >bNumConfigurations: 0x01 > > > >ie Cypress VID/PID > > > >Where to now? presumably forcing a pipe somehow > > You already know more about USB than I do. :-) > > However, I wonder if the data in the serial EEPROM are checksummed, in > which case it may be possible to confirm its integrity. > > ISTM that you've at least confirmed that the EZ-USB chip has sanity, > if you weren't already convinced by your scope tests. > > - Franc Zabkar > -- > Please remove one 'i' from my address when replying by email. Switching SDA line after 3 seconds still keeps the USB open but wrong identity for the mixer firmware installer. Not had a chance to connect it up to a pc but I'm assuming it will not software connect if expecting the mixer VID/VID/endpoint. When next I have some time I will load the installer.exe into hex_reader_XVI32 and see if I can swap VID / PID hex-codes to fool it into thinking it is an EZbus rather than EZusb it is hooked to. Probably checksummed there but simple enough to try.
|
Next
|
Last
Pages: 1 2 3 Prev: AC current sensor with interface Next: ? on NTE56041 for touch-on lamp |