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.

That gives me a lot to look into next week , if it should be quiet.
The other thing I cannot find is a "reverse" VID/PID lookup source .
In this particular case the code for Event (maker) Ezbus (product) or
perhaps subclass of "digital mixer" to find a www reference to what the
Ezbus USB ident code should be.
Confusingly Ezbus product uses Ez-usb chip.


From: Franc Zabkar on
On Sat, 8 May 2010 09:57:29 +0100, "N_Cook" <diverse(a)tcp.co.uk> put
finger to keyboard and composed:

>The other thing I cannot find is a "reverse" VID/PID lookup source .
>In this particular case the code for Event (maker) Ezbus (product) or
>perhaps subclass of "digital mixer" to find a www reference to what the
>Ezbus USB ident code should be.

The PID and VID should be in the INF file in the driver / firmware
updater, EzBus.inf.

[DeviceList]
%DESCRIPTION0%=DriverInstall,USB\VID_0B45&PID_0000
%DESCRIPTION1%=DriverInstall,USB\VID_0B45&PID_0001&MI_04

DESCRIPTION0="EZbus - Needs firmware refresh"
DESCRIPTION1="EZBus Control Surface Engine"

- 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:8hhau517eb5vgm967d672mqvugsu945jh6(a)4ax.com...
> On Sat, 8 May 2010 09:57:29 +0100, "N_Cook" <diverse(a)tcp.co.uk> put
> finger to keyboard and composed:
>
> >The other thing I cannot find is a "reverse" VID/PID lookup source .
> >In this particular case the code for Event (maker) Ezbus (product) or
> >perhaps subclass of "digital mixer" to find a www reference to what the
> >Ezbus USB ident code should be.
>
> The PID and VID should be in the INF file in the driver / firmware
> updater, EzBus.inf.
>
> [DeviceList]
> %DESCRIPTION0%=DriverInstall,USB\VID_0B45&PID_0000
> %DESCRIPTION1%=DriverInstall,USB\VID_0B45&PID_0001&MI_04
>
> DESCRIPTION0="EZbus - Needs firmware refresh"
> DESCRIPTION1="EZBus Control Surface Engine"
>
> - Franc Zabkar
> --
> Please remove one 'i' from my address when replying by email.

I'm a late developer at this sort of stuff. I'd downloaded that Event1 stuff
but not unzipped it / run it and would not have expected that info there
anyway. I would have thought that would be in a higher/lower? level of
maker masked/loaded ROM or PROM not potentially user eraseable EEPROM . So
the problem now looks less daunting and explains why the situation can arise
of corrupted upload/ blocked reload/ dead kit.

As I type, a moulded (to be perforated) guard band to go over the 0.8mm pin
spacing 80 pin EZ-usb chip is just cooling down so I can safely probe with
scope/Thurlby DSA524/ Thurlby LA160 etc. I should say cooling down over an
80 pin HD61602 LCD driver chip as a matching plug or mould or whatever the
casting term is.
The 2 memory devices are a bit more approachable


From: N_Cook on
Taken some readings (not repeated so maybe not pin for pin correct)
EZ-bus
post-POST situation
Logical Analyser LA160 not used yet
pin /function * DVM "volts DC" (steady av voltage of pulse train ) * scope
trace

1 DISCON# * 3.3
2 VCC * 3.3
3 GND * 0
4 CLK24 * 1.6 * 23.997MHz
5 GND * 0
6 GND * 0
7 A0 * 1.5 * high speed data
8 A1 * 1.5 * high speed data
9 A2 * 1.5 * high speed data
10 A3 * 1.4 * high speed data
11 A4 * 1.7 * high speed data
12 A5 * 1.5 * high speed data
13 GND * 0
14 GND * 0
15 A6 * 1.4 * 40uS word length data
16 A7 * 1.2 * 40uS word length data
17 GND * 0
18 AGND * 0
19 XIN * 1.4
20 XOUT * 1.4
21 AVCC * 3.3
22 VCC * 3.3
23 GND * 0
24 EA * 0
25 RESET * 0
26 A8 * 2.3
27 A9 * 0.7
28 A10 * 1
29 A11 * .5
30 PC0/RxD0 * 5
31 PC1/TxD0 * 3.3
32 PC2/INT0# * .08
33 PC3/INT1# * 5
34 A12 * 1.2 * 40uS word length data
35 A13 * .5 * 40uS word length data
36 A14 * .5 * 40uS word length data
37 A15 * .6 * 40uS word length data
38 PC4/T0 * 0
39 PC5/T1 * 3.3
40 PC6/WR# * 3.2
41 PB7/T2out *3,3
42 VCC * 3.3
43 GND * 0
44 PB0/T2 * 0
45 PB1/T2EX * 0
46 PB2/RxD1 * 5
47 PB3/TxD1 * 3.3
48 D0 * .6 * 40uS word length data, 3 level
49 D1 * .7 * 40uS word length data, 3 level
50 D2 * .5 * 40uS word length data, 3 level
51 D3 * .5 * 40uS word length data, 3 level
52 PB4/INT4 * 5
53 PB5/INT5# * 5
54 PB6/INT6 * .07
55 PC7/RD# * .07
56 GND * 0
57 D4 * 1.8 * 40uS word length data, 3 level
58 D5 * .4 * 40uS word length data, 3 level
59 D6 * .9 * 40uS word length data, 3 level
60 D7 * 1.8 * 40uS word length data, 3 level
61 BKPT * 0
62 VCC * 3.3
63 GND * 0
64 SDA * 3.3
65 SCL * 3.3
66 WAKEUP# * 3.3
67 NC * 0
68 PA0/T0out * 3.3
69 PA1/T1out * 0
70 PA2/OE# * 0
71 PA3/CS# * 2.9
72 GND * 0
73 PA4/FWR# * 3.3
74 PA5/FRD# * 3.3
75 PA6/RXD0out * 5
76 PA7/RXD1out * 0
77 USBD- * .04
78 GND * 0
79 USBD+ * 3.3
80 PSEN# * 2.9 * 40uS word length data


24LC128 EEPROM voltages
1, A0, always H
2, A1 ,always L
3, A3 ,always L
4, Vss, 0V
5, SDA, data burst at switch on , about 2sec gap, then burst post POST
6, SCL, clock bursts as p5
7,WP , L
8 , Vcc, 3.3V






From: N_Cook on
SCL bursts, from scope, bit less than100KHz, datasheet says 90.9 KHz
I intend firstly reading and storing on disc, the SDA stream but have lost
the LA160 to pc RS232 lead so will have to make another one first