Prev: instructor solution manual for Reinforced Concrete: Mechanics and Design (5th Ed., James G. MacGregor & James K. Wight)
Next: Rob@welzijnpernis.speedlinq.nl
From: N_Cook on 8 May 2010 04:57 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 8 May 2010 07:18 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 8 May 2010 08:55 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 9 May 2010 11:34 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 10 May 2010 03:35
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 |