View 8X930HX_1699104.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

release date: february, 1999 order number: 272962-013 notice: the 8x930h x may contain design defects or errors known as errata which may cause the product to deviate from published specifications. current characterized errata are documented in this specification update. 8x930h x (8x930hd/he & 8x930hf/hg) specification update
information in this document is provided in connection with intel products. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. except as provided in intel's terms and conditions of sale for such products, intel assumes no liability whatsoever, and intel disclaims any express or implied warranty, relating to sale and/or use of intel products including liability or warranties relating to fitness for a particular purpose, merchantability, o r infringement of any patent, copyright or other intellectual property right. intel products are not intended for use in medical, life saving, or life sustaining applications. intel may make changes to specifications and product descriptions at any time, without notice. the 8x930h x may contain design defects or errors known as errata which may cause the product to deviate from published specifications. current characterized errata are available on request. contact your local intel sales office or your distributor to obtain the latest specifications and before placing your product o rder. copies of documents which have an ordering number and are referenced in this document, or other intel literature may be obtained by calling 1-800-548-4725 or by visiting intel's website at http://www.intel.com. copyright ? intel corporation, 1998. *third-party brands and names are the property of their respective owners. ii february, 1999 272962-013
272962-013 february, 1999 iii contents revision history ...........................................................................1 preface ............................................................................................2 summary table of changes .....................................................4 identification information .......................................................8 errata .............................................................................................10 specification changes .............................................................24 specification clarifications .................................................27 documentation changes .........................................................32

8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 1 of 34 revision history rev. date version description 10/09/96 001 this is the new specification update document. 11/13/96 002 added errata numbers 9611001, 9611002, and 9611003. added a-1 stepping information. 12/10/96 003 deleted erratum number 9610001. this erratum does not exist in the 8x930h x a1 stepping. added workaround to erratum number 9611002 . added erratum 9612001 . added specification clarification 002 . added documentation changes 001 , 002 , 003 , 004 , 005 , and 006 . 1/8/97 004 added erratum 9701001 . deleted specification clarification 002 . it does not apply to the 8x930h x . added documentation changes 007 and 008 . added information for stepping a3. 2/5/97 005 added documentation changes 009 , 010 , 011 , and 012 . 3/4/97 006 added erratum number 9702001 . added specification changes for ac and dc characteristics. added 64-pin sdip package marking information. 4/15/97 007 added documentation changes 013 , 014 , and 015 . 5/30/97 008 added 8x930hf0/hg0 stepping information. added errata numbers 9705001 , 9705002 and 9705003 . added specification clarifications 002 , 003 , and 004 . 7/10/97 009 added firmware workaround to erratum number 9705003 . added erratum 9706001 . 11/4/97 010 added errata numbers 9711001 , 9711002 , and 9711003 . 4/7/98 011 added erratum 9804001 . added vcc and ecap voltage range to specification clarification 002 . 6/1/98 012 added specification changes 003 , 004 and 005 . added documentation change number 016 . 2/5/99 013 added workaround #2 to erratum 9612001 .
8X930HX (8x930hd/he & 8x930hf/hg) specification update 2 of 34 february, 1999 272962-013 preface as of july, 1996, intel has consolidated available historical device and documentation errata into this document type called the specification update. we have endeavored to include all documented errata in the consolidation process, however, we make no repre- sentations or warranties concerning the completeness of the specification update. this document is an update to the specifications contained in the affected documents/related documents table below. this document is a compilation of device and documentation errata, specification clarifications and changes. it is intended for hardware system manufacturers and software developers of applications, operating systems, or tools. information types defined in nomenclature are consolidated into the specification update and are no longer published in other documents. this document may also contain information that was not previously published. nomenclature errata are design defects or errors. these may cause the published (component, board, system) behavior to deviate from published specifications. hardware and software designed to be used with any component, board, and system must consider all errata documented. specification changes are modifications to the current published specifications. these changes will be incorporated in any new release of the specification. specification clarifications describe a specification in greater detail or further highlight a specifications impact to a complex design situation. these clarifications will be incorpo- rated in any new release of the specification. documentation changes include typos, errors, or omissions from the current published specifications. these will be incorporated in any new release of the specification. affected documents/related documents title order 8X930HX universal serial bus peripheral controller data sheet 272928-003 8x930ax, 8X930HX universal serial bus microcontroller users manual 272949-001
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 3 of 34 note: errata remain in the specification update throughout the products lifecycle, or until a particular stepping is no longer commercially available. under these circumstances, errata removed from the specification update are archived and available upon request. specifi- cation changes, specification clarifications and documentation changes are removed from the specification update when the appropriate changes are made to the appropriate product specification or user documentation (datasheets, manuals, etc.).
8X930HX (8x930hd/he & 8x930hf/hg) specification update 4 of 34 february, 1999 272962-013 summary table of changes the following table indicates the errata, specification changes, specification clarifications, or documentation changes which apply to the 8x930h x product. intel may fix some of the errata in a future stepping of the component, and account for the other outstanding issues through documentation or specification changes as noted. this table uses the following notations: codes used in summary table steps x: errata exists in the stepping indicated. specification change or clarification that applies to this stepping. (no mark) or (blank box): this erratum is fixed in listed stepping or specification change does not apply to listed stepping. page (page): page location of item in this document. status doc: document change or update will be implemented. fix: this erratum is intended to be fixed in a future step of the com- ponent. fixed: this erratum has been previously fixed. nofix: there are no plans to fix this erratum. eval: plans to fix this erratum are under evaluation. row change bar to left of table row indicates this erratum is either new or modified from the previous version of the document.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 5 of 34 errata number steppings page status errata hd1/ he1 hd3/ he3 hf0/ hg0 hf2/ hg2 9611001 x x 10 fixed non-stop noacknowledging (nak) with ohci systems 9611002 x 10 fixed hub may accidentally be recognized as a low-speed device 9611003 x x x x 12 fix v oh on port 1, 2, and 3 are below target specification 9612001 x 12 fixed receive fifo rxffrc error 9701001 x 15 fixed downstream j-k signal duty cycle not symmetrical 9702001 x x 15 fixed transmit fifo underrun 9705001 x x 17 fixed low speed end of packet (eop) errata 9705002 x x x 17 fixed serial port auto address recognition errata 9705003 x x x 18 fixed isochronous transfer rxcnt errata 9706001 x x x 20 fixed timer 2 idle mode wake up errata 9711001 x x x 21 fixed incorrect response on receive fifo overflow in low clock mode 9711002 x x x x 21 fix timer and interrupt flags are not set when the tcon sfr is modified simultaneously with an external interrupt 9711003 x x x x 22 fix pca capture flag is not set when a capture occurs with pca timer overflow 9804001 x x x x 22 fix interrupts of 3 or more priority levels occurring at the same time specification changes (sheet 1 of 2) number steppings page status specification changes hd1/ he1 hd3/ he3 hf0/ hg0 hf2/ hg2
8X930HX (8x930hd/he & 8x930hf/hg) specification update 6 of 34 february, 1999 272962-013 001 x x 24 doc revise datasheet status from product preview to advance information 002 x x 24 doc added 8x930hf0/hg0 stepping information to datasheet 003 x x x x 26 doc series resistor requirement for impedance matching changed to 22 ohms (no longer 27 C 33 ohms) 004 x x x 26 doc added 8x930hf2/hg2 stepping information to datasheet 005 x 26 doc ecap output voltage supply does not vary with vcc specification clarifications number steppings page status specification clarifications hd1/ he1 hd3/ he3 hf0/ hg0 hf2/ hg2 001 x x x 27 doc t rhdz1 timing 002 x x x 30 doc ecap pin usage to supply 3.0 v to 3.6 v voltage for 1.5k ohm usb pullup terminator 003 x x x 31 doc txcntx must be written with correct byte count 004 x x x 31 doc unused d px and d mx pins must be pulled down 005 x x x 13 doc receive fifo rxffrc error specification changes (sheet 2 of 2)
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 7 of 34 documentation changes number document revision page status documentation changes 001 001 32 doc nonvolatile memory verification port labeled incorrectly 002 001 32 doc incorrect address given for txstat sfr 003 001 32 doc incorrect signature byte 004 001 32 doc power-on reset capacitor value changed 005 001 32 doc scon sfrs ren bit description incorrect 006 001 32 doc extraneous footnote in rxcon sfr 007 001 33 doc power off flag voltage values 008 001 33 doc w clk description incorrect 009 001 33 doc configuration byte misspelled 010 001 33 doc rtwce description inaccurate 011 001 33 doc rl instruction misspelled 012 001 33 doc footnote incorrect in data instructions table 013 001 34 doc hardware, not firmware, sets fe bit in scon register 014 001 34 doc reset value of lc bit (pcon.5) should be 1 015 001 34 doc incorrect ovri# signal description 016 001 34 doc remove sdip package reference throughout the datasheet
8X930HX (8x930hd/he & 8x930hf/hg) specification update 8 of 34 february, 1999 272962-013 identification information markings product part number stepping marking package comment 8X930HX step 1 n80930hd1 hd1/ he1 no marking plcc shipping media = tubes q 831 plcc customer sample no rom sl24d plcc general production, romless shipping media = tape & reel n83930hd1 r xxxx plcc 8k rom customer rom code n83930he1 r xxxx plcc 16k rom customer rom code 8X930HX step 3 n80930hd3 hd3/ he3 q 807 plcc general customer sample, romless n80930hd3 sl26k plcc general production, romless, shipping media = tape & reel n80930hd3 no marking plcc general production, romless, shipping media = tubes n83930hd3 r xxx plcc general production, 8k rom n83930he3 r xxx plcc general production, 16k rom
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 9 of 34 markings (continued) product part number stepping marking package comment 8X930HX step 0 n80930hf0 hf0/ hg0 q871 68ld plcc general customer sample, romless n8030hf0 sl27f 68ld plcc general production, romless, shipping media = tapen reel n80930hf0 no marking 68ld plcc general production, romless, shipping media = tubes n80930hf0 r xxx 68ld plcc general production, 8k rom n80930hg0 r xxx 68ld plcc general production, 16k rom 8X930HX step 2 n80930hf2 hf2/ hg2 q871 68ld plcc general customer sample, romless n8030hf2 sl27f 68ld plcc general production, romless, shipping media = tapen reel n80930hf2 no marking 68ld plcc general production, romless, shipping media = tubes n80930hf2 r xxx 68ld plcc general production, 8k rom n80930hg2 r xxx 68ld plcc general production, 16k rom
8X930HX (8x930hd/he & 8x930hf/hg) specification update 10 of 34 february, 1999 272962-013 errata 9611001 . non-stop noacknowledging (nak) with ohci systems problem: while in low-clock mode (lc bit = 1), clearing the rxsetup bit while the transmit fifo data register is transmit ready (transmit ready = data in the transmit fifo data register and a byte-count in the txcnt register) could cause the part to continuously nak in response to an in token. this will occur until the transmit fifo data register is reset and reloaded. this only happens with ohci where the bus turnaround is very fast. implication: if this condition occurs, the serial bus interface engine will continue to nak even though there is data in the transmit fifo data register. workaround: software workaround is available. the user needs to make sure that the rxsetup bit is cleared before the transmit fifo register becomes transmit ready. status: fixed. refer to summary table of changes for affected steppings. 9611002. hub may accidentally be recognized as a low-speed device problem: when a self-powered, suspended hub is reattached to the host, it could be accidentally recognized as a low-speed device. this is caused by the 8x930h x a-1 driving k signaling upstream and the host incorrectly sampling the speed of the device immediately after connect instead of after usb reset. implication: enumeration will fail due to the host sending low-speed packets to a high-speed device. workaround: to fix this problem, you must modify the reset circuitry on current 8x930h x designs. figure 1 depicts two circuits, one for a bus-powered hub and another for a self-powered hub. for bus powered devices, the circuit is the same one that is given in figure 14-1 on page 14-1 of the 8x930ax, 8X930HX universal serial bus microcon- troller users manual , except the capacitor value has been changed from 1.0 f to 0.3 f. for self-powered devices there are two requirements: ? the reset circuit design needs to be activated when the board is first powered-on. ? if the board is already powered-on, then a connection to the host should initiate reset. by connecting another capacitor to v bus (c2, as shown in figure 1 ), a reset pulse is sent to the chip by either a power-up or by a usb connect.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 11 of 34 figure 1. rst source from v cc and v bus the circuit shown in figure 1 uses the following components: ? c1 used in conjunction with the internal pulldown resistor to generate a 20 ms pulse of reset. for bus-powered devices, v cc = v bus . this creates a 20 ms pulse upon connection to the host. for self-powered devices, a 20-ms pulse will occur regardless of the state of v bus if the capacitor ratios remain 1:1. the circuit operation and timing relationships rely on c1 = c2. ? c2 used only for self-powered devices. the capacitor delivers a 20-ms pulse to the rst pin when the v bus signal is detected upon device connection. ? r1 provides a discharge path for c2. this resistor is mandatory. if r1 is not present, c2 will not discharge the reset pulse and therefore will not allow a proper chip reset during device connection. status: fixed. refer to summary table of changes for affected steppings. a5336-01 this side needed for both self- and bus-powered devices this side needed only for self-powered devices v cc = 5v v bus of upstream port = 5v 40k w -225k w (internal pulldown resistor) c1 0.3f c2 0.3f r1 ~200k w (discharge path for 0.3f capacitor) rst (pin 41) 930h x
8X930HX (8x930hd/he & 8x930hf/hg) specification update 12 of 34 february, 1999 272962-013 9611003. v oh on port 1, 2, and 3 are below target specification problem: when port 1, 2, and 3 are in quasi bidirectional mode, their v oh s are below the target specification as shown: v oh = v cc - 0.8 v (instead of v cc - 0.3 v) @10 a v oh = v cc - 1.7 v (instead of v cc - 0.7 v) @30 a v oh = v cc - 2.7 v (instead of v cc - 1.5 v) @60 a implication: the fanout of port 1, 2, and 3 pins are reduced. workaround: external buffers can be used to provide the required drive capability needed for interfaces that require more drive than the 8x930h x can support. status: fix. refer to summary table of changes for affected steppings. 9612001 . receive fifo rxffrc error problem: after the rxffrc bit of the rxcon register is set, the rxfif1:0 bits in the rxflg register remain 11. according to specifications, rxfif1:0 should immediately decrement when rxffrc is set. this problem occurs when the following conditions are simultaneously met: 1. the function interface unit (fiu) and serial bus interface engine (sie) write a byte count to the rxcntl sfr of endpoint 1s receive fifo. 2. the cpu sets the rxffrc bit for any other endpoints receive fifo (not endpoint 1). 3. the receive fifo for the endpoint in ( 2 ) has rxfif1:0 bits = 11. this problem is most likely to occur in low-clock mode when the device has a high data receive rate (bulk mode) on endpoint 1 and one or more of the other receive fifo endpoints. implication: when the problem occurs, having rxfif1:0 remain as 11 will cause firmware to incorrectly assume that there are two packets left in the receive fifo (in dual packet mode), when in reality there is only one packet left. if firmware attempts to read the non-existent second packet, hardware will set the rxurf bit. when the rxurf bit gets set, the 8x930h x continues to nak all out packets on the affected fifo. at this point, the fifo will be in an unknown state, requiring firmware to reset/clear that fifo. workaround: #1 (if you experience 1/3 data loss with this workaround, try workaround #2) additional code must be added to the firmware location(s) where a non-endpoint 1 receive fifo is released. this code must determine if the rxfif1:0 bits are 11 before and after setting the rxffrc bit. if this is true, and if the rxseq bit has not been toggled by hardware during this time, then the error has occurred. at this point,
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 13 of 34 firmware must attempt to release the receive fifo again by re-setting the rxffrc bit. this process must be repeated until the receive fifo is successfully released. insert a firmware routine similar to the example shown in figure in your code at the point where you release the receive fifo for all endpoints except endpoint 1. the code must be duplicated for each endpoint (except endpoint 1), replacing the x in the examples code labels with the endpoint number. ;******************************************************* ; rxffrc firmware workaround ;******************************************************* ; note: registers 11 through 14 are utilized in this example. ; please be sure to save and restore these registers as needed. release_fifo_x: mov a, rxflg mov r12, rxflg ; before mov r13, rxstat setb rxffrc ; if (rxflg_before = rxflg_after) ; then { continue and check if rxfif="11" } ; else { setting rxffrc was successful } cjne a, rxflg, rel_fifox_ok ; if we get here r11 has rxflg before and after - no ; change mov r14, rxstat ; if (rxflg_after = "11") ; then { continue and check rxseq data toggle } ; else { jump to rel_fifox_ok} anl r11, #11000000b ; check rxfif after cjne a, #11000000b, rel_fifox_ok ; rxfif bits are "11" rxflg="c0" ; if (rxseq_before = rxseq_after) ; then ; { no data toggle - set rxffrc again } ; else ; { data toggle - ok jump to rel_fifox_ok} anl r13, #10000000b anl r14, #10000000b cmp r13, r14 jne rel_fifox_ok figure 2. rxffrc firmware workaround
8X930HX (8x930hd/he & 8x930hf/hg) specification update 14 of 34 february, 1999 272962-013 workaround: #2 make sure that if workaround #1 was attempted, that you backout of the workaround. then, set rxffrc as usual but ignore rxcnt entirely. use a read routine of rxdat that reads it until rxurf is set and then clear rxurf. an example is provided below that can be a subroutine from within the sof or can be put in-line as well. the following example is a code suggestion only and responsibility of verification of the workaround lies with the customer as each implementation and application will be different. also note that this workaround may cause issues with performance sensitive applications and some fine tuning or simliar algorithms may need to be engineered. read_rxdata_routine: ; push registers here as required by your application moredata: ; read rxdat in scratch buffers mov r3, rxdat mov r2, rxdat ; if rxurf then we've read past the end of the fifo jb rxurf, nomoredata ; good data, move to r5 and r4 (or wherever you want the data) mov r5, r3 mov r4, r2 ; try to read more data sjmp moredata nomoredata: clr rxurf ; with this setup you will always read until rxurf so it always needs to be ; cleared every time ; now pop whatever registers you pushed and return ret status: fixed. refer to summary table of changes for affected steppings. ; fifo errata condition: rxfif was "11" before & after; & ; rxstat didn't change release_fifo_x_again: ljmp release_fifo_x rel_fifox_ok: figure 2. rxffrc firmware workaround (continued)
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 15 of 34 9701001 downstream j-k signal duty cycle not symmetrical problem: customers cannot cascade 8x930h x hubs up to the maximum allowable five tiers as specified by the universal serial bus specification , version 1.0. this problem occurs because the j-k duty cycle of the 8x930h x usb differential signal is not symmetrical. therefore, the signaling marginality worsens when more 8x930h x hubs are cascaded. timeouts may occur on the host and/or on the device. if an end function device using an a3-stepping 8 x 930a x is connected to the 8x930h x hubs, it works well only up to four tiers of 8x930h x hubs. if an end function device using an a2-stepping 8 x 930a x is connected to the 8x930h x hubs, it works will only up to two tiers of 8x930h x hubs. if an end function device using an a3-stepping 8 x 930a x (or any other usb device with a symmetrical duty cycle for the j-k signaling) is connected to the hubs, it works well up to four tiers of 8x930h x cascaded with another tier using a hub with a symmetrical duty cycle for the j-k signaling. the maximum allowable cascading of hubs specified by the universal serial bus specifi- cation , rev. 1.0, is: host/root hub-->1st tier hub-->2nd tier hub-->3rd tier hub-->4th tier hub-->5th tier hub-->end function device. implication: if 8x930h x hubs are cascaded more than the number of tiers described above, the usb device attached to the last tier hub will not function correctly. workaround: no workaround. status: fixed. refer to summary table of changes for affected steppings. 9702001 . transmit fifo underrun problem: when setting the txclr coincides with an in token received, the transmit fifo (txfifo) will be underrun. this will happen when all the following conditions are met: a. the rxsetup bit is set b. an in token is received c. setting the txclr bit implication: when the problem occurs, the txfifo will be in underrun error condition (txurf bit set). if the txurf bit is not checked by the firmware and is not cleared properly, the 8x930h x will continue to nak all the in tokens on the affected txfifo.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 16 of 34 february, 1999 272962-013 workaround: additional code must be added to the firmware wherever it is applicable. this code must determine if the rxsetup bit is set, then set the txclr bit twice or more if necessary to make sure the txfifo is cleared. when the txfifo is successfully cleared, all the flags (especially txfifo underrun flag, txurf) in the txflg register are cleared except for the empty flag (txemp) which will be set. insert a firmware routine similar to the example shown in figure 3 in your code wherever it is necessary. the code must be duplicated for each transmit endpoint, replacing the x in the example code labels and the epindex register with the proper endpoint number for hub or for embedded function. status: fixed. refer to summary table of change for affected steppings. figure 3. transmit fifo underrun firmware workaround clear_txfifo_xx: mov epindex, #x0h ; hub or embedded function endpoint 0 mov a, rxstat jb acc.6 clear_again_xx ; jump if rxsetup bit is set mov epindex, #xxh ; related hub or embedded function endpoint number orl txcon, #10000000b ; set txclr bit sjmp end_clear_txfifo_xx: clear_again_xx: mov epindex, #xxh ; related hub or embedded function endpoint number orl txcon, #10000000b ; set txclr bit mov a, txflg jb acc.1, clear_again_xx ; jump if txurf is set sjmp end_clear_txfifo_xx end_clear_txfifo_xx:
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 17 of 34 9705001 low speed end of packet (eop) errata problem: low speed devices connected to downstream ports of the 8x930hdx hub peripheral controller may lose connectivity after an undetermined period of time due to noise glitches on the usb input pins. these glitches on the input pins result in the 8x930hdx recognizing a valid signal transition during a eop signal, causing the eop signal to be detected incorrectly by the hub. this problem occurs when all of the following conditions occur simultaneously: 1. the glitch happens at the end of the eop signal from the downstream low speed device. 2. the amplitude of the glitch is more than 100mv due to the hysteresis margin on the input pins. 3. the asynchronous glitch happens at a critical internal clock sampling node. 4. the glitch happens within 20ns of the signal reaching the rising trip threshold (~1v @ vcc=5v). implication: when this problem occurs, the hub fails to properly detect a valid eop from the downstream low speed device. the hub then detects a babble condition at the end of frame on the offending port and disables the port. the low speed device connected to that port will stop communicating with the host. the user will need to unplug and re-plug in the low speed device again to recover from this condition. workaround: as with any design, it is very important to design the usb circuit board to suppress noise. noise usually originates from the power plane or the usb cable. for the 8x930hdx, analysis has shown that if noise glitches are limited to less than 100mv on usb pins, this problem will not occur. also note that if the 8x930hdx device is run in low clock mode (pcon.5=1), the possibility of this failure is dramatically reduced. customers should migrate their designs to the new 8x930hfx 4 external downstream port hub peripheral controller. a document titled design considerations when migrating between intel's 8x930hd3 and 8x930hf0 usb hub controllers has been posted on the web at: developer.intel.com/design/usb/papers . status: fixed. please refer to summary table of changes for a list of affected steppings. 9705002 serial port auto address recognition errata problem: when the 8X930HX serial port is configured to use auto address recognition feature in multiprocessor communication by setting the sm2 bit in scon register, the 8x930h x cannot automatically recognize the sent slave (given) address and broadcast address. this applies to serial port modes 1, 2, and 3.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 18 of 34 february, 1999 272962-013 implication: when configured to use this feature, the serial port cannot recognize automatically the given address and broadcast address sent to it. as such, the serial port receive interrupt, ri flag in scon register will not be set, and no interrupt will be generated. this errata is not applicable to serial port mode 0 as it does not support this feature. workaround: manually check the address if multiprocessor communication, using serial port, is needed. to avoid enabling the auto address recognition feature, do not set the sm2 bit in scon register. the ri flag is set and interrupt is generated with every serial data received. in the serial port receive interrupt service routine, check the rb8 bit in scon register to determine if the serial data received is an address byte (rb8=1) or a data byte (rb8=0). if it is the address byte and the address matches with a pre-assigned address, then read the serial data bytes on the subsequent receive interrupts until next address byte is received. if the address byte does not match with the pre-assigned address, then ignore the subsequent serial data bytes received until next address byte is received. status: fixed. please refer to summary table of changes for a list of affected steppings. 9705003 isochronous transfer rxcnt errata problem: when the 8x930h x is configured to use dual packet mode in isochronous transfer, the receive fifo count register (rxcntx) of the new data packet is corrupted if the read completion of the previous data packet (setting rxffrc bit) coincides with receive done of the new data packet. implication: when this problem occurs, the 8x930h x will read an incorrect value from the rxcntx register on the new data packet and hence read an incorrect number of bytes from the receive fifo. with that, the data read will be either shorter or longer than actually received, the data read will not be correct, and the receive fifo will overflow or underrun. workaround: at the end of an isochronous data read in the start of frame (sof) isr, do not release the rxfifo by setting the rxffrc bit. in the very beginning of the next sof interrupt service routine, before the next out token arrives, set the rxffrc bit to release the rxfifo that was read in the previous frame. this will prevent the read completion of the previous data packet (setting rxffrc bit) from coinciding with the receive done of the new data packet. an example of a firmware workaround is shown in figure status: .
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 19 of 34 status: fixed. please refer to summary table of changes for a list of affected steppings. ;****************************************************************************************************** ; isochronous transfer endpoint 1 initialization code ; > use a direct address ram location (eg. 30h) to store a value for setting or not setting rxffrc bit: ; > [30h] = 0ch ->not to set rxffrc bit, ; > [30h] = 1ch ->to set rxffrc bit, ;****************************************************************************************************** iso_ep1_init: mov 30h, #0ch ;other endpoint 1 initialization code ret ; example endpoint 1 initialization routine ; do not set rxffrc bit when entering sof isr for the ;first time ;****************************************************************************************************** ; start of frame (sof) interrupt service routine ; > rxffrc bit is set to release the isochronous data packet that was read in previous frame ;****************************************************************************************************** ; sof_isr: push epindex mov epindex, #01h mov rxcon, 30h ; example endpoint 1 isochronous transfer isr ; select iso endpoint 1 ; set or do not set rxffrc bit depends on value ;in 30 ; do not add additional instructions before this line; rxffrc bit must be set before out token arrives push psw push psw1 push acc push r3 clr asof ;clear sof interrupt flag ; ep1_rx_isoc: ;example iso receive processing routine jb rxfif0, ep1_rx_data_avail jb rxfif1, ep1_rx_data_avail mov 30h, #0ch ljmp exit_sof_isr ; no iso data packet received, dont ;setrxffrc bit in next frame ; ep1_rx_data_avail: mov 30h, #1ch jnb rxerr, ep1_no_rx_error ljmp handler_rx1_error_x (continued) ; to set rxffrc bit in next frame as it is read in this ;frame ; jump to iso receive error handling routine figure 4. isochronous transfer rxcntx errata firmware workaround example
8X930HX (8x930hd/he & 8x930hf/hg) specification update 20 of 34 february, 1999 272962-013 9706001 . timer 2 idle mode wake up errata problem: when the 8x930h x is in idle mode, the interrupt generated by the timer 2 is not able to wake up the cpu. the timer 2 interrupt can be generated in various modes by timer or counter overflow, or by capturing an external high-to-low transition signal on t2ex pin. implication: when this problem occurs, the 8x930h x will remain in the idle mode. the cpu will not wake up, and the timer 2 interrupt service routine will not execute. note that this erratum is not applicable to powerdown mode operation as all peripherals (including timer 2) and the cpu stop running in powerdown mode. powerdown mode is required when the 8x930h x is suspended by usb to meet the suspend current specifi- cation. idle mode is not. workaround: there is no workaround when using timer 2 to wake up the 8x930h x cpu from idle mode. if timer 2 service is needed, use another unused interrupt such as timer 0 or 1, or external interrupt 0 or 1. synchronize it with timer 2 to wake up the cpu in idle mode and then jump to timer 2 service routine. status: fixed. refer to summary table of changes for affected steppings. ;****************************************************************************************************** ; start of frame interrupt service routine, continued ;****************************************************************************************************** ; ep1_no_rx_error: mov a, rxcntl jz exit_sof_isr mov r3, a ; get the receive count ; temp storage of rxcntl ; rx_loop_x: mov a, rxdat ; read the iso data received ; process the data here, such as save to memory etc djnz r3, rx_loop_x ; exit_sof_isr: pop r3 pop acc pop psw1 pop psw pop epindex reti ; restore any registers used figure 4. isochronous transfer rxcntx errata firmware workaround example (continued)
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 21 of 34 9711001 incorrect response on receive fifo overflow in low clock mode problem: intermittently, the device will respond incorrectly to an out token from the host, which causes an rxfifo overflow. instead of timing out and setting the appropriate flags, the device will occasionally ack the data, signalling a valid reception of data. 1. device is running in low clock mode (pcon.5 is set). 2. host incorrectly sends one additional byte to the rxfifo, that is, the total length sent has to be equal to 1 + physical maximum endpoint size. 17 bytes for endpoint 0 and 5, 33 bytes for endpoint 2, 3, and 4, and 1025 bytes for endpoint 1. the correct response is a usb timeout.the rxemp and rxovf bits in the rxflg sfr should be set. the rxack should be cleared and rxseq should remain unchanged. implication: the host will see an ack instead of a timeout and the fifo is in an unknown state. the host and the device will be out of sequence. workaround: no workaround is available. under normal operation, endpoints 0 and 5 are configured as an 8-byte fifo single/dual packet mode, endpoints 2, 3, and 4 are configured as a 16-byte fifo single/dual packet mode, and endpoint 1 should be configured as a 512 byte dual-packet mode if used in isoc transfer type. status: fixed. refer to summary table of changes for affected steppings. 9711002 timer and interrupt flags are not set when the tcon sfr is modified simultaneously with an external interrupt problem: when the control bits (it0, it1, tr0 and tr1) in the tcon sfr are set or cleared at the same instance as an edge-triggered external interrupt(s) is generated, the ie0 and/or the ie1 flag(s) will not be set. therefore, no external interrupt will be generated. for a level-sensitive triggered external interrupt, the interrupt flag will continue to be set until the external source is removed from the int0# or int1# pins. similarly, when the control bits (it0, it1, tr0, and tr1) in the tcon sfr are set or cleared at the same instance the timer0 or timer1 overflows, the it0 and/or it1 flag(s) will not be set. therefore, no timer0/timer1 interrupt will be generated. implication: application will not be able to detect that an external event has happened. as for the timer, it must wait for another 256/65535 machine cycles before another timer overflow interrupt is generated. workaround: do not modify the tcon control bits after the timer has been started or the external interrupt bits are enabled. if the control bits require modification when a timer is enabled, timer2 or pca timer can be used instead. if two timers are required, and the control bits require modification, a combination of timer0 and timer1 or timer1 and
8X930HX (8x930hd/he & 8x930hf/hg) specification update 22 of 34 february, 1999 272962-013 timer2 can also be used for it0 and it1 to remain set if timer2 control bits in t2con sfr are modified. if external interrupts are required and the control bits in the tcon sfr require modifying, use a level-sensitive type triggered interrupt to set the ie0 and ie1 flags upon clearing/setting control bits in the tcon sfr. status: fix. refer to summary table of changes for affected steppings. 9711003 pca capture flag is not set when a capture occurs with pca timer overflow problem: when the pca is used in capture mode, the capture flag (ccfx) in the ccon sfr will not be set upon a positive/negative edge signal on the cexx pin. this only happens when the pca timer overflows at exactly the same instance as the positive/negative edge signal on the cexx pin. implication: the device may not detect a capture event. workaround: the firmware can be coded so that the pca timer never overflows, thus setting the pca capture flag. another option would be to enable the pca timer overflow (cf) in the ccon sfr. to do this, clear the ccapxh and ccapxl registers to values other than ff00h. upon an overflow of the pca timer, the firmware checks the ccapxh and ccapxl registers for any new values. if there is a value of ff00h in the sfr pair, ccapxh/ccapxl, a capture event has occurred. clear both registers to values other than ffh and 00h, respectively, for the next capture event. status: fix. refer to summary table of changes for affected steppings. 9804001 interrupts of 3 or more priority levels occurring at the same time problem: when three interrupts of different priorities occur at approximately the same time (~40 nsec. window) on the 8x930 peripheral controllers, the lowest priority interrupt will not be serviced correctly. as the lower priority interrupt is interrupted by a higher priority interrupt, the internal interrupt pending bit remains set and the device believes it is still servicing the lowest priority interrupt. this disables any further lowest priority interrupts from being serviced. any interrupt source can be affected by this if it is the lowest priority of the three enabled interrupts. for example, if external interrupt 0 (int0) is priority 3, start of frame (sof) interrupt is priority 2, and serial port (sio) interrupt is priority 0, and they all occur at the same time, then the sio interrupt would stop being serviced.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 23 of 34 if four different interrupt priority levels are used, then both priority 0 and 1 interrupts would stop being serviced. implication: this will cause the lowest priority interrupt to no longer be serviced and the interrupt will not recover unless a device reset occurs. workaround 1: to insure this interrupt priority conflict does not occur, make sure only two interrupt priority levels are enabled at any given time. workaround 2: once the device is in the failing condition and the lower priority interrupt(s) are no longer being serviced, there is a possible software workaround for some applications. this workaround involves detecting the fail event, manually pushing a return address on the stack, and executing a reti instruction. the user will have to evaluate if this workaround will apply to their application. example: main_code: ljmp int_fail_fix org ff1500h continue main code . . . int_fail_fix: push #00h push #15h reti how it works: the users main program code (main_code) detects the failing condition. one method of doing this would be reading the appropriate interrupt pending bit and starting a timer when this bit was set. if the interrupt is not serviced in a specified amount of time, the program would jump to the int_fail_fix routine. the int_fail_fix routine pushes the address of the instruction after the ljmp to int_fail_fix,1500 in this case.the reti instruction will return the program counter to 1500. this will pop the internal interrupt stack so that it will handle future lowest priority interrupt(s). status: fix. refer to summary table of changes for affected steppings.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 24 of 34 february, 1999 272962-013 specification changes 001 . revise datasheet status from product preview to advance information the 8X930HX universal serial bus peripheral controller data sheet, product preview version (order number 272928-001) has been revised to advance information datasheet (order number 272928-002). refer to the summary table of changes for affected steppings. the changed specifications are listed in the following tables: table 1. dc characteristics symbol parameter min typical ( 1 ) max units test conditions i pd powerdown current normal powerdown usb suspend 25 145 75 (was 50) 175 a i dl idle mode i cc 60 (was 40) ma full speed (in low clock mode) pllsel2:0 = 110 f clk = 3 mhz 110 (was 100) full speed (not in low clock mode) pllsel2:0 = 110 f clk = 12 mhz i cc active i cc 75 (was 70) ma full speed (in low clock mode) pllsel2:0 = 110 f clk = 3 mhz 170 full speed (not in low clock mode) pllsel2:0 = 110 f clk = 12 mhz note: 1. typical values are obtained using v cc = 5.0 v, t a = 25 c and are not guaranteed.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 25 of 34 table 2. ac characteristics symbol parameter cpu frequency @ 12 mhz (m, n = 0) cpu frequency (f clk ) variable units min max t avll address valid to ale low 21.66 (was 28.66) (0.5+m)t clk C 20 (was -13) ns t llax address hold after ale low 4 (was 10) 4 (was 10) ns t wlwh wr# pulse width 71.33 (was 73.33) (1+n)t clk C 12 (was -10) ns t llrl ale low to rd# or psen# low 4 (was 5) 4 (was 5) ns t lhax ale high to address hold 40.33 (was 56.33) (1+m)t clk C 43 (was -27) ns t rhdz 2 data float after rd# or psen# high 83.33 (was 93.33) t clk (was + 10) ns t rhlh 2 rd# or psen# high to ale high (data) 83.33 (was 93.33) t clk (was + 10) ns t whlh wr# high to ale high 88.33 (was 93.33) t clk + 5 (was +10) ns t avdv 1 address (port 0) valid to valid data/instruction in 98.66 (was 106.66) (2+m+n)t clk C 68 (was -60) ns t avdv 3 address (port 2) valid to valid instruction in 23.33 (was 35.33) (1+n)t clk C 60 (was -48) ns t avrl address valid to rd# or psen# low 37.33 (was 56.33) (1+m)t clk C 46 (was -27) ns t avwl 1 address (port 0) valid to wr# low 37.33 (was 56.33) (1+m)t clk C 46 (was -27) ns t avwl 2 address (port 2) valid to wr# low 66.33 (was 83.33) (1+m)t clk C17 (was -0) ns
8X930HX (8x930hd/he & 8x930hf/hg) specification update 26 of 34 february, 1999 272962-013 002 . added 8x930hf0/hg0 stepping information to datasheet the 8X930HX universal serial bus peripheral controller data sheet, advance information version (order number 272928-003) has been revised to include 8x930hf0/hg0 infor- mation. 003. series resistor requirement for impedance matching changed to 22 ohms (no longer 27 C 33 ohms) section 8.4 of the 8X930HX universal serial bus peripheral controller data sheet has been changed. to better match the output driver impedance, the recommended resistance is 22 ohms. 004 . added 8x930hf2/hg2 stepping information to datasheet the 8X930HX universal serial bus peripheral controller data sheet, advance information version (order number 272928-004) has been revised to include 8x930hf2/hg2 infor- mation. 005 . ecap output voltage supply does not vary with vcc the voltage at the ecap pin can be used to provide the pullup voltage for the 1.5kohm resistor. the voltage required for the pullup is between 3.0v to 3.6v per the usb specifi- cation, revision 1.0. ecap voltage of the 8x930hf2/hg2 does not change when vcc changes and the typical voltage at the ecap pin is 3.1v (unlike the 8x930hf0/hg0 devices where the output voltage at the ecap pin varies with vcc).
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 27 of 34 specification clarifications 001 . t rhdz1 timing problem: the t rhdz 1 (instruction float after rd#/psen# high) specification on the 8x930h x when operating at 12 mhz is 10 ns. however, a slow memory device such as an eprom typically takes approximately 30 C 90 ns to float its output. (this specification, generically called t phz , may vary depending on the memory type and manufacturer.) figures 5 and 6 illustrate the t rhdz 1 timing. the difference between the t rhdz 1 and t phz specifications causes contention on the data bus (p0 in nonpage page, p2 in page mode). the 8x930h x begins to drive the address for the next bus cycle while the memory device is still driving data from the previous bus cycle. figure 5. external code fetch, nonpage mode ale rd#\psen# p0 a17/a16/p2 a5011-01 state 1 state 1 (next cycle) state 2 t lhll t llrl t rlrh t rlaz t llax t avll t avdv1 t avdv2 t lhax instruction in a7:0 a17/a16/a15:8 t rhdx t rhdz1 t rhlh1 t avrl t rldv
8X930HX (8x930hd/he & 8x930hf/hg) specification update 28 of 34 february, 1999 272962-013 figure 6. external code fetch, page mode to prevent this contention, designers can use a buffer to isolate the output of the memory device from the data bus (port 0 or port 2) of the 8x930h x . this will prevent the memory device from driving the data bus during the critical period after t rhdz1 expires. we suggest a buffer such as the 74f541 octal, three-state line driver shown in figure 7 . ale rd#\psen# p2 a17/a16/p0 a5028-02 state 1 state 2 t lhll t llrl t rlrh t rlaz t llax t avll t avdv1 t avdv2 t lhax instruction 1 in a15:8 a17/a16/a7:0 t rhdz1 t rhlh1 t avrl t rldv t rhdx instruction 2 in t avdv3 cycle 2, page hit state 1 cycle 1, page miss ? during a sequence of page hits, psen# remains low until the end of the last page hit cycle. ?
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 29 of 34 figure 7. example bus contention solution for 8X930HX (nonpage mode) a5103-02 d8:1 q8:1 le oe# 74ac373 74f541 p0.7:0 ale 8x930 p3.7/rd#/a16 p1.7/cex4 /a17/wclk p3.6/wr# psen# p2.7:0 q8:1 128k eprom a7:0 a15:8 a16 oe# ce# d7:0 128k ram a15:8 a16 we# oe# cs1# 74ac04 a7:1 y7:0 oe1# oe2# cs2# a7:0 v cc wr# a17 a17 a16 psen# psen# ad7:0 d7:0 a16
8X930HX (8x930hd/he & 8x930hf/hg) specification update 30 of 34 february, 1999 272962-013 figure 5 illustrates the connections of an 8x930h x configured for nonpage mode with eprom and ram in external memory. if your system uses a different configuration, your circuit will be different from the example. the 74f541 is enabled to pass data from the eprom to the 8x930h x (port 0) when oe1# and oe2# are active. table 3 is a truth table for the 74f541. table 3. truth table for 74f541 during a read, psen# turns the buffer on (oe1# and oe2# are active), connecting the eproms output to the 8x930h x s port 0. when psen# goes high after a read, oe1# and oe2# are deasserted, and the buffers output switches to the high-impedance state in approximately 9.5 ns (t phz for a typical 74f541; the value may vary from one manufacturer to another). thus, contention on the data bus is prevented. this or a similar hardware solution is recommended for 8X930HX designs in which memory devices do not meet the t rhdz 1 timing specification. 002 . ecap pin usage to supply 3.0 v to 3.6 v voltage for 1.5k ohm usb pullup terminator item: for a self-powered or bus-powered device, when the voltage at the v cc pins are at 5.25 v to 4.15v, the voltage at ecap pin will be at approximately 3.6 v to 3.0v. if the v cc pin is at 4.65 v [min, vbus powered (host or hub) port specification], the voltage at the ecap pin will be at approximately 3.2 v (refer to table 4 below). the capability for this pin to supply the 3.0 v to 3.6 v voltage to the 1.5 k ohm usb pullup terminator depends upon the v cc voltage level. for a bus-powered device that is connected to a bus-powered hub, when the voltage at the v cc pins (in the bus-powered devices) are at 4.28 v, the voltage at ecap pin will be at approximately 3.0 v. if the v cc voltage drops below 4.28 v, the ecap pin cannot supply voltage above 3.0 v for the 1.5 k ohm usb pullup terminator. inputs outputs oe1# oe2# a7:1 y7:1 l l l l l l h h x h x z h x x z
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 31 of 34 note: the typical ecap values, listed in the table below, reflect a 1 f capacitor connection between the ecap pin and ground. table 4. vcc and typical ecap voltages 003 . txcntx must be written with correct byte count problem: both the transmit count registers, txcnth and txcntl of the 8x930h x embedded function transmit endpoint 1 must be written with the correct byte count after moving data into the transmit fifo data register (txdat). when transmitting less than 256 bytes (ffh), the user must initially write txcnth with 00h, and then stage txcntl with the correct transmit byte count. the 8x930ax, 8X930HX user's manual (order number 272949-001) page numbers 7-17, 7-19 and c-69 contain incorrect descriptions for the reset state of the txcnth register, endpoint 1. the reset state of both txcnth and txcntl registers are indeterminate. 004 . unused dpx and dmx pins must be pulled down problem: the unused usb downstream ports pins must be pulled low so that the input pins are not floated. connect both unused d px and d mx pins on the unused downstream port with a 15k w resistor to ground respectively to simulate a disconnect state. v cc ecap pin 5.25v 3.6v 5.00v 3.5v 4.65v 3.2v 4.40v 3.1v 4.28v 3.0v
8X930HX (8x930hd/he & 8x930hf/hg) specification update 32 of 34 february, 1999 272962-013 documentation changes 001 . nonvolatile memory verification port labeled incorrectly item: the illustration setup for verifying nonvolatile memory (figure 17-1 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual ) incorrectly depicts p1 as the verify modes port. the correct port for verify modes is p0. 002 . incorrect address given for txstat sfr item: the usb function sfr tables (tables 3-11 and c-7) in the 8x930ax, 8X930HX universal serial bus microcontroller users manual give an incorrect address for the txstat sfr. the correct address is s:f2h. 003 . incorrect signature byte item: section 17-6 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual mentions a signature byte at 61h. there is no signature byte at 61h. 004 . power-on reset capacitor value changed item: figure 14-1 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual depicts a 1 f power-on reset capacitor. the correct value for this capacitor is 0.3 f. 005 . scon sfrs ren bit description incorrect item: the description for the serial port control sfrs ren bit (scon.4), as given in figure 13-2 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual , is incorrect. the text should say: to enable reception, set this bit. to disable reception, clear this bit. the scon sfr also appears in appendix c of the same manual. 006 . extraneous footnote in rxcon sfr item: the dagger footnote ( ? ) does not apply to the rxffrc and rxiso bits in the rxcon sfr, as shown in figure 7-15 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual . the rxcon sfr also appears in appendix c. note that the dagger footnote does apply to the sfrs advwm and revwp bits.
8X930HX (8x930hd/he & 8x930hf/hg) specification update 272962-013 february, 1999 33 of 34 007 . power off flag voltage values item: section 15.2.2 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual states that the hardware sets the power off flag (pof) in pcon when v cc rises from < 3 v to > 3 v to indicate that on-chip volatile memory is indeter- minate...since for v cc < 3 v data may have been lost or some logic may have malfunc- tioned. the voltage value should be 3.5 v for all references, not 3 v. 008 . w clk description incorrect item: the description for the wait clock output (w clk ) given in table 16-1 and table b-2 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual is incorrect. instead of when enabled, the w clk output produces a square wave signal with a period of one-half the oscillator frequency, the final sentence should read when enabled, the w clk output produces a square wave signal with a period of t clk . 009 . configuration byte misspelled item: on page 16-11 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual , in the third paragraph of the note, unconfig0 should be uconfig0. 010 . rtwce description inaccurate item: on page 16-11 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual , in figure 16-11, the description of rtwce should say with rtwe set, setting rtwce will enable the wait clock...... in other words, setting rtwce alone will not enable the wait clock, both bits must be set. 011 . rl instruction misspelled item: on page a-4 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual , the 'a' should be moved to the second line for rla and rlca. the instruction is rl a not rla. 012 . footnote incorrect in data instructions table item: on page a-6 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual , note 2 for table a-9 is not correct. orl, anl, and xrl all have one instruction that uses drk (see page a-38 for an example).
8X930HX (8x930hd/he & 8x930hf/hg) specification update 34 of 34 february, 1999 272962-013 013 . hardware, not firmware, sets fe bit in scon register item: on page 13-7 of the 8x930ax, 8X930HX universal serial bus microcontroller users manual , under section 13.3 in the first paragraph, in the last sentence it should read: if a valid stop bit is not found, the hardware sets the fe bit in the scon register. 014 . reset value of lc bit (pcon.5) should be 1 item: on pages 15-3 (figure 15-1), and c-43, the reset value for the lc bit in the pcon register (pcon.5) reads x but should read 1 since low clock mode is automatically set after a reset. 015 . incorrect ovri# signal description item: on page b-5 (table b-2), the ovri# description should read: sense input to indicate an overcurrent condition for a self-powered usb device on an external downstream port. this pin is active low with an internal pullup. 016 . remove sdip package reference throughout the datasheet item: the following sdip package information has been removed from the 8X930HX universal serial bus peripheral controller data sheet, advance information version (order number 272928-004): figure 5 on page 7, table 7 on page 9, and table 9 on page 11.

▲Up To Search▲

Price & Availability of 8X930HX

	To Download 8X930HX Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .