From: N_Cook on
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
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
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
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
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.