AN2401 Application note

Transcription

1 Application note upsd3400 USB firmware Introduction The upsd3400 combines a high-performance 8051-based microcontroller with numerous peripherals to facilitate the design of complex applications. Many applications require some sort of control or data communications with a host computer. While communication over a standard RS-232 serial link was the norm, USB (Universal Serial Bus) is becoming more and more popular. In many cases, the only serial port available on newer PCs is a USB port. The upsd3400 not only includes two UARTs used with typical RS-232 communication, but it also includes a full-speed (12 Mbps) USB port. This application note covers the various aspects of the USB port included in the device related to firmware control. It is highly recommended that the USB interface chapter of the upsd3400 datasheet be read first and available for reference as needed while reading this application note. It is also assumed that the reader is familiar with the USB specification and the terminology used. Additionally, several USB firmware examples for the upsd3400 are available on ST's website. They can be found at: under Support Files for the upsd family. July 2006 Rev 1 1/18

2 Contents AN2401 Contents 1 upsd3400 USB firmware Firmware responsibility USB SIE clock Endpoint FIFOs FIFO pairing Endpoint related interrupts Bus signaled events RESET SUSPEND and RESUME Control transfers USB address Endpoint receive mode Endpoint transmit mode USB endpoint control register (UCON) ENABLE STALL TOGGLE USB interrupt service routine (ISR) framework Treatment of USEL in the USB ISR - single FIFO usage Treatment of USEL in the USB ISR - double FIFO usage Revision history /18

3 upsd3400 USB firmware 1 upsd3400 USB firmware 1.1 Firmware responsibility The USB SIE (Serial Interface Engine) is responsible for automatically handling many of the low level protocol tasks relieving the firmware of that burden. Interrupts are only generated by the USB SIE when data has been successfully transmitted/received or when special signaling on the bus is generated or detected. The firmware is responsible for handling the following: 1. Decoding and handling incoming control requests sent with SETUP packets. 2. Preparing data to be sent to the host in response to IN packets. 3. Unloading data received from the host with OUT packets. 4. Handling of events indicated on the bus (Suspend, Reset, and Resume). 5. Managing the state of the USB device and responding to the host requests appropriately. Figure 1 below shows a block diagram of the USB module within the upsd3400. Please refer to the data sheet for an explanation of each of the blocks within it. Figure 1. USB module block diagram Clock PLL 3-40MHz 48MHz Endpoint MCU D D+ USB USB+ USB Transceiver Serial Interface Engine Endpoint0 Endpoint0 IN FIFOs (64 bytes each) FIFO Interface Logic OUT FIFOs (64 bytes each) XDATA CTRL S F R B u s USB SFRs Endpoint4 CTRL CTRL and Data SETUP Command Buffer (8 bytes) CTRL and Data AI USB SIE clock The USB SIE (Serial Interface Engine) requires a 48 MHz clock for proper operation. Included in the upsd3400 is a PLL that provides many options for obtaining a 48 MHz clock from various main clock frequencies. It is important to select a main clock crystal or oscillator frequency that can be used with the PLL to generate the 48 MHz clock. The USB_CLK section in the MCU CLOCK GENERATION chapter contains the details for the PLL with respect to setting it up to generate a 48 MHz clock from the main clock. Also 3/18

4 upsd3400 USB firmware AN2401 included is a table with some common main clock frequencies and some example PLL settings to generate a 48 MHz clock. An important thing to note is that the PLL lock time is 200 µs, so firmware should wait that amount of time after setting the PLL multiplier and divider bits in registers CCON0/1 before enabling the PLL (controlled by the UPLLCE bit in register CCON0). 1.3 Endpoint FIFOs The host PC transfers data between itself and a USB device through endpoints. From a device's standpoint, an endpoint is a FIFO. From the host's standpoint, an endpoint is either a destination for data that it sends to the device or a source of data that it has requested from the device. There are various types of data transfers (control, interrupt, bulk, or isochronous) and two directions of transfer, IN and OUT. IN transfers are from the device to the host and OUT transfers are from the host to the device. Each of the 5 endpoints in the upsd3400 has a FIFO for both IN and OUT directions for a total of 10 FIFOs. Each FIFO is 64 bytes in length resulting in a total of 640 bytes of FIFO. The endpoint FIFOs are accessible through a 64-byte window in the XDATA space. The base address for this window is written into two registers, UBASEH and UBASEL. The lower 5 bits of the base address is hardwired to "0", so the base address is aligned on 64-byte boundaries. The base address should be set to any available 64-byte window in the XDATA space not occupied by any external device, internal memory, or the CSIOP registers. Since the window into the XDATA memory space to access the FIFOs is through a 64-byte window, the particular endpoint to be accessed must be selected using the USEL register. There are three bits in that register that specify an endpoint number and another bit that specifies the direction. Using the USEL register, the endpoint FIFO of interest is accessed. The endpoint FIFOs are always available to the USB SIE, but are not available to firmware by default (after a hardware reset). The FIFO is made accessible by setting the VISIBLE bit in the USB control register (UCTL). For most applications it is only necessary to initially make the FIFO visible and this bit is not touched after that. 1.4 FIFO pairing For more efficient bulk data transfers, the FIFOs can be paired so the MCU can operate on one packet of data while another is being transferred over USB. Pairing is done on an odd endpoint basis, such that pairing on endpoint 1 uses endpoint 1's FIFO plus endpoint 2's FIFO (making endpoint 2 no longer available). The same is true for endpoint 3, such that when pairing is enabled, endpoint 3's FIFO and endpoint 4's FIFO is used and endpoint 4 is no longer available. From a firmware standpoint when pairing is enabled, the second FIFO is transparent and all transactions (status, interrupts, etc.) take place with respect to endpoint 1 and the hardware handles switching back and forth between accessing FIFO #1 and FIFO #2. By default (after a hardware reset), pairing is turned off. To enable pairing on an endpoint and direction basis, the UPAIR register must be written appropriately. Important Note: When FIFO pairing is enabled, in the background the hardware manages whether it is using endpoint 1 or endpoint 2's FIFO, status register, etc. This is handled by hardware, so firmware is not burdened with this overhead. However, the FIFO or status register actually being used by the hardware is indicated by the USEL register. For example, assuming there are 128 bytes of data to send to the host over endpoint 1, the firmware first writes to the USEL register to select endpoint 1 and then writes the data to the 4/18

5 upsd3400 USB firmware FIFO. After writing to the USIZE register (which arms the FIFO), the USEL register changes from 1 to 2. If firmware were to write a 1 to the USEL register and were to read it back, it would still be a 2. This is because the next FIFO to be loaded is for endpoint 2. Firmware would then check the FIFO status and would see that it is not full (even though the contents were not transferred yet). The firmware then writes data to the FIFO (that actually goes into endpoint 2 FIFO), and then sets the USIZE register. If USEL were read back, it would still be a 2. After the host sends an IN packet to the device and the first 64 bytes are transferred, a 1 would be read from USEL register. So, when FIFO pairing is used, always treat the pair as endpoint 1 and don't be concerned with what the hardware is doing in the background. The only time that USEL needs to be read is to save and restore it in the ISR (see the ISR section for further details). 1.5 Endpoint related interrupts There are three interrupts related to each endpoint, IN FIFO, OUT FIFO, and IN FIFO NAK. The IN FIFO interrupts indicate that a particular FIFO was transmitted successfully. The OUT FIFO interrupts indicate that the particular FIFO is full (a packet of data has been received from the host). The third interrupt, IN FIFO NAK, indicates that the host sent an IN token to the device and the device sent a NAK response. The device only sends a NAK response when there is no data available in the FIFO to send to the host. This particular interrupt is generally not used but in some applications it may be helpful to tell when the host is requesting data from the device signaling to the firmware to gather or generate the data to send in response. Each endpoint's three interrupts can be selectively enabled to generate an interrupt. All USB event related interrupts vector to the same location and the interrupt service routine firmware is responsible for checking the interrupt flag registers to determine the exact cause of the interrupt and process it accordingly. Since all USB event generated interrupts vector to the same location, the priority is determined by the order that the interrupt flags are checked and processed. 1.6 Bus signaled events RESET There are three bus conditions that indicate special events. Such events include RESET, SUSPEND, and RESUME. These events cause an interrupt, if enabled, when detected by hardware. These events must be processed appropriately for the device to operate properly on the USB so it is recommended that interrupts be used to handle these events. A USB RESET indicates that the host is resetting the device. Firmware, after detecting a RESET, should set the device back to the default state. A USB RESET, when detected by the hardware, does not reset the device as does a hardware reset (a reset via the reset pin). It sets a few USB registers back to their default power on state (or hardware reset) but does not affect all pertinent registers. In the data sheet, with each register definition, it is indicated what the reset value is after a hardware and also a USB reset. Since a USB RESET does not set the USB address register back to zero, it is critical that firmware writes a zero to the UADDR register. There are a few other registers that must be written with a particular value to get back to the default state. A USB RESET function may look like the following: 5/18

6 upsd3400 USB firmware AN2401 void OnUsbReset() /****************************************************************************** Function : void OnUsbReset() Parameters : none Description: USB driver module initialization routine. ******************************************************************************/ UCTL &= ~USBEN; //USB disable/enable resets the UCTL = USBEN; // USB state machine USTA = 0; UADDR = 0; UIF1 = 0; UIF2 = 0; UIF3 = 0; UIF0 = 0; brstf = 0; bsuspendf = 0; UIE0 = RSTIE SUSPENDIE; UIE1 = IN0IE; UIE2 = OUT0IE; UIE3 = 0; UIE1 = IN1IE; UIE2 = OUT2IE; //Reset device address //Enable RESET and SUSPEND interrupts //Enable EP0 IN interrupts //Enable EP0 OUT interrupts //Disable all NAK interrupts //Enable EP1 IN interrupts //Enable EP2 OUT interrupts //Enable endpoint FIFOs and clear busy bits USEL = OUTDIR SELEP0; //Select EP0 OUT UCON = ENABLE_FIFO EPFIFO_BSY; USEL = INDIR SELEP0; UCON = ENABLE_FIFO; //Select EP0 IN USEL = OUTDIR SELEP2; //Select EP2 OUT UCON = ENABLE_FIFO EPFIFO_BSY; USEL = INDIR SELEP1; //Select EP1 IN UCON = ENABLE_FIFO; confignum = 0; usbstate = US_DEFAULT; Important Note for revision A of the silicon: If CPUPS in CCON0 is anything other than 000b, then a reset is not detected. This is corrected in Rev B SUSPEND and RESUME Suspend and resume detection by the hardware is always enabled. Interrupts are generated, if enabled, when these events are detected. When a suspend event is detected, the SUSPENDF bit in the UIF0 register is set. If the SUSPENDIE bit in the UIE0 register is set, an interrupt is generated. The hardware shuts down the clock to the SIE when a suspend event is detected to conserve power. When a resume event is detected, the RESUMF bit is set and an interrupt is generated if that interrupt is enabled. The RESUMIE bit in the UIE0 register enables the interrupt. Upon detection of a resume event, firmware must clear the SUSPENDF bit to enable the clock to the SIE for processing of USB transactions. 6/18

7 upsd3400 USB firmware Below is a piece of some code taken from the example USB ISR code in Figure 4 that shows the handling of the suspend and resume interrupt: if (bsuspendf) if (bresumef) // If Resume interrupt occurred UIE0 = SUSPENDIE; // Enable the suspend interrupt UIE0 &= ~RESUMEIE; // Disable the resume interrupt OnUsbResume(); // Process the resume interrupt bresumef = 0; // Clear the resume interrupt flag bsuspendf = 0; // Clear the suspend interrupt flag else // A suspend interrupt is detected UIE0 = RESUMEIE; // Enable the resume interrupt UIE0 &= ~SUSPENDIE; // Disable the suspend interrupt OnUsbSuspend(); // Process the suspend interrupt A typical system may require additional tasks to be performed when the host signals a suspend or resume on USB such as managing power of the device or external devices. In a simple system, only the USB state flag is changed as shown in the example code below: void OnUsbSuspend() /****************************************************************************** Function : void OnUsbSuspend() Parameters : none Description: service routine for USB Suspend event ******************************************************************************/ usbstate = US_SUSPENDED; void OnUsbResume() /****************************************************************************** Function : void OnUsbResume() Parameters : none Description: service routine for USB Host resume event ******************************************************************************/ usbstate = US_DEFAULT; 1.7 Control transfers Control transfers are used to configure and send commands to a device. Control transfers consist of two or three stages. They always consist of Setup and Status and optionally contain a data stage in between. During the Setup stage, a SETUP packet is used to transmit information to the control endpoint of a function. SETUP transactions are similar in format to an OUT but use a SETUP rather than an OUT PID. Figure 2 shows the SETUP packet format. A SETUP always uses a DATA0 PID for the data field of the SETUP transaction. Per the USB specification, the function receiving a SETUP packet must always accept the SETUP data and respond with ACK. If the data is corrupted, the data is discarded and no response is sent to the host rather than a NAK. This is all handled by the USB SIE hardware -- no interrupts or status bits are set so no firmware processing is required. Note that when a host does not receive an ACK from a device in 7/18

8 upsd3400 USB firmware AN2401 response to a SETUP packet, it assumes that the device did not receive the packet properly and resends it. Figure 2. Control SETUP transaction Idle Token SETUP Data DATA0 Handshake ACK Error Idle Host Function Assuming the device receives a Setup packet with no transmission errors, it responds with an ACK. After the ACK is sent, the USB SIE immediately generates an OUT0/Setup interrupt. A Setup packet is similar to an OUT0 packet in that the OUT0F flag is set and an OUT interrupt is generated. By checking the SETUP flag in the USTA register, firmware can determine if a Setup packet was received or if it was only an OUT0 packet (OUT0 packet data goes to the OUT0 FIFO). When a Setup packet is received, the 8 bytes of data sent are put into the USB Setup Command register (USCV). In the USB ISR, the firmware checks the UIF0 (USB Global Interrupt Flag) register and sees that the OUT FIFO (OUTF) bit is set. Firmware then checks the SETUP bit in the USTA (USB Endpoint 0 Status) register and when set, knows that a SETUP packet was received. Firmware uses the USB Setup Command Index register (USCI) to read out the 8 command bytes from the USB Setup Command value register (USCV). An example of the code to read out the 8 command bytes is shown below: void ReadSetupPacket(void) /****************************************************************************** Function : ReadSetupPacket() Parameters : none Description: Reads a setup packet from USB Setup Command Register. ******************************************************************************/ data unsigned char i; unsigned char* p = (unsigned char*) &setuppacket; USTA &= ~SETUP; // Clear setup bit in USTA for (i=0; i<8; i++) 8/18

9 upsd3400 USB firmware USCI = i; *p++ = USCV; After the SETUP packet data has been read from the USCI register, the request from the host must be decoded and processed accordingly. If present, the Data stage of a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers. All the transactions in the Data stage must be in the same direction (i.e., all INs or all OUTs). The amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the pre-negotiated data packet size, the data is sent in multiple transactions (INs or OUTs) that carry the maximum packet size. Any remaining data is sent as a residual in the last transaction. The Status stage of a control transfer is the last transaction in the sequence. The status stage transactions follow the same protocol sequence as bulk transactions. A Status stage is delineated by a change in direction of data flow from the previous stage and always uses a DATA1 PID. If, for example, the Data stage consists of OUTs, the status is a single IN transaction. If the control sequence has no Data stage, then it consists of a Setup stage followed by a Status stage consisting of an IN transaction. Figure 3. Control Read and Write sequences Setup Stage Data Stage Status Stage Control Write SETUP (0) DATA0 OUT (1) DATA1 OUT (0)... OUT (0/1) DATA0 DATA0/1 IN (1) DATA1 Control Read SETUP (0) DATA0 IN (1) DATA1 IN (0)... IN (0/1) OUT (1) DATA0 DATA0/1 DATA1 Setup Stage Status Stage No-data Control SETUP (0) DATA0 IN (1) DATA1 Figure 3 shows the transaction order, the data sequence bit value, and the data PID types for control read and write sequences. The sequence bits are displayed in parentheses. 1.8 USB address When a device is first connected to the bus, the USB address register (UADDR) is set to 0x00. The host always starts general enumeration of a newly discovered device on the bus using address 0x00. The device only responds to bus traffic with the address in the UADDR register. After the host gathers some basic information from the device on the default address of 0x00, it sends a SET_ADDRESS request to the device providing a 7-bit address. The device, upon decoding a SET_ADDRESS request, writes the 7-bit address into UADDR. After UADDR is written, the device will only respond to the host with that address and no longer the default address, 0x00. Since the UADDR register takes immediate effect as soon as it is written, it is important to write the assigned address to UADDR after the status stage of the SET_ADDRESS request. 9/18

10 upsd3400 USB firmware AN2401 A set address command follows the No-data Control sequence as shown in Figure 3. The SET_ADDRESS command consists of the host sending a SETUP packet to address 0 and endpoint 0. The data sent with the SETUP packet is the SET_ADDRESS command plus the address assigned to the device. When the firmware receives a SET_ADDRESS command, it temporarily stores the address in RAM and changes a state flag to indicate the USB state is a set address request. It also enables the IN0 FIFO with a zero bytes. The host then sends an IN PID and the device responds with a zero length data packet. After the SIE sends the ACK, an IN interrupt is generated. The USB ISR sees that the interrupt was an IN0 and the state flag is set for an address request. At this point, the firmware writes the address received from the host into the UADDR register and changes the USB state back to the default. Now, the device has a new address and responds only to packets with this address. When the host sends a subsequent packet, it is no longer on address 0 but on the newly assigned address and the device responds only to packets with this new address. When a SET_ADDRESS command is received from the host, the function that processes that command changes the USB state to a value that indicates it is a set address command but does not write the address value to UADDR since the address of the device must be 0x00 when it receives the Status Stage from the host. In this case, the Status Stage consists of a zero length data packet. It is only after the Status Stage is received that the UADDR register should be written with the assigned address. An example of the function that processes the Set Address is simply as follows: void OnSetAddress() /****************************************************************************** Function : void OnSetAddress() Parameters : none Description: Handler for SET_ADDRESS packets ******************************************************************************/ usbstate = US_ADDRESSED; TransmitZeroLengthEP0(); Below is a piece of some code taken from the example USB ISR code in Figure 4 that shows the setting of the USB address register (UADDR) after the Status. Basically, if an IN interrupt occurred and it was on endpoint 0 and the usbstate was US_ADDRESSED (which indicates the processing of the SET_ADDRESS request from the host), the UADDR register is written with the new address. The address is the value received from the host with the last setup packet and is stored in setuppacket.wvalue.lo. /* IN packets servicing */ if (binf) if (UIF1 & IN0F) // EP0 IN UIF1 &= ~IN0F; TransmitEP0(); if (usbstate == US_ADDRESSED) UADDR = setuppacket.wvalue.lo; // new device address usbstate = US_DEFAULT; After the new address is written to UADDR, the device responds only to packets with that address. 10/18

11 upsd3400 USB firmware 1.9 Endpoint receive mode When the device receives an OUT packet from the host, the USB SIE puts the received data into the target endpoint's FIFO. After all bytes have been received, the SIE performs a CRC check of the data against the CRC it received from the host. If the CRC check is good, then the SIE responds with an ACK, sets the OUTxF (x = the endpoint number) interrupt flag, and generates an interrupt. The ISR, upon determining that an OUT interrupt condition occurred (by reading the UIF0 register), then reads the UIF2 register to determine the endpoint that received the packet of data. The data is then read out of the endpoint's FIFO and the FIFO is rearmed making it ready to receive another packet of data. To read the data out of the endpoint's FIFO, the appropriate endpoint FIFO is selected with the USEL register. The USEL register is written with bit 7 (DIR) set to a "1" for the OUT direction and bits 2:0 with the endpoint number. After selecting the appropriate FIFO, the USIZE register is read to determine how many bytes were received into the FIFO. For the OUT direction, the USIZE register always indicates the number of bytes that were received into the FIFO. The data is then read out of the XDATA space where the USB FIFO was located as specified by the UBASEH and UBASEL. After the data is read out, the FIFO is rearmed by writing any value to the USIZE register. Until USIZE is written after a packet has been received, the SIE will NAK all subsequent OUT packets to that endpoint since the FIFO is full and hasn't been rearmed Endpoint transmit mode When the host wants to receive data from a device, it sends an IN packet. If the endpoint's FIFO has data, the device sends the contents; otherwise, no data is sent and the request is NAKed. When the device has data to send to the host, it loads the FIFO and then writes into the USIZE register the number of bytes to send to the host with an IN request. Writing to the USIZE register arms the FIFO for transmission and also tells the SIE how many bytes to send to the host. In addition, the endpoint's BSY (Busy) bit is set indicating that the FIFO is full and awaiting for transmission to the host. Even though the FIFO is 64 bytes in length, only the number of bytes specified by USIZE are sent. When the device detects an IN packet from the host, it sends the data that is in the FIFO. If the device does not receive an ACK from the host, the SIE assumes there is an error and leaves the FIFO armed. When the host sends the next IN packet, the device retransmits the data. Once the device detects an ACK from the host, it changes the status of the FIFO to not busy, indicating that it is empty and another packet of data can be loaded. To load the particular endpoint's FIFO with data to send to the host with an IN request, the USEL register is written with the DIR bit cleared (indicating an IN FIFO) and the EP bits set to the endpoint number. The data is then written to the FIFO and USIZE is written with the number of bytes to transmit. Writing to the USIZE register changes the state of the BSY bit in the UCON register from a 0 to a 1 indicating that the FIFO if full (or armed). When the next IN packet for that endpoint is received, the SIE transmits the FIFOs contents. After the FIFO's contents are successfully transmitted and the ACK is received from the host, the BSY bit is cleared. The BSY bit should be used to tell when the FIFO is full or empty, and when empty, can load the FIFO with new data to send. 11/18

12 upsd3400 USB firmware AN USB endpoint control register (UCON) ENABLE STALL Each endpoint has a couple of other bits in the control register (UCON) that are important to mention and were not previously described. Those bits are the ENABLE, STALL, and TOGGLE. The operation of the BSY bit in the UCON register was described in the endpoint transmit and receive sections. The ENABLE bit determines whether the SIE responds to requests on this endpoint. If the endpoint is not enabled, then the SIE ignores all packets from the host for this endpoint and provides no response on the bus. Also, no interrupt flags are set nor any interrupts generated. The FIFO must be enabled in order for the SIE to properly respond to host requests on this endpoint. Important Note: When a FIFO is enabled (after being in a disabled state), the TOGGLE (data toggle bit) is set to a TOGGLE Another important bit is the STALL bit. There are certain cases when this bit should be used. When the bit is set, the SIE responds to all packets from the host on this endpoint with a STALL packet. This bit, when set, remains set until firmware clears it. For IN endpoints, the TOGGLE bit indicates what the data toggle is to be set to (DATA0 or DATA1) for the DATA packet response to the next IN packet from the host. This is a read only bit indicating what the SIE will send. The SIE automatically toggles this bit when an ACK is received from the host in response to a successfully transmitted packet. If the SIE transmits the data and does not receive an ACK, the data toggle bit does not toggle. The packet is retransmitted with the next IN packet. In cases where the data toggle must be reset, disabling and re-enabling the endpoint FIFO (using the ENABLE bit) resets the data toggle. For OUT endpoints, the TOGGLE bit indicates what the data toggle should be with the next OUT packet that is received. If the data toggle is as expected, then the transmission is considered good and the appropriate OUT interrupt flags are set and an interrupt is generated. If the data toggle is not as expected, the SIE assumes the host is retransmitting the last packet it sent. The host retransmits a packet if it doesn t properly receive an ACK from the device with the last OUT packet that was sent on the particular endpoint. If the device had sent the ACK but some noise corrupted the packet, the host believes that the device did not receive the packet; therefore, it retransmits it with the same data toggle. The device, seeing the same data toggle as was received with the previous packet, assumes the host is retransmitting the packet. Since the device successfully received the last packet, it discards the retransmitted packet and doesn't set any interrupt flags or generate any interrupts. It does, however, respond with an ACK to the retransmitted packet. The host, upon receiving the ACK this time, toggles its data toggle and now the host and the device are back in sync. As is the case with IN endpoints, if there is a need for the data toggle to be reset, the endpoint FIFO should be disabled and re-enabled. Important Note: For revision A silicon, disabling and enabling an endpoint's FIFO does not reset the data toggle. For cases where the data toggle is a "1" and its bit must be reset ("0"), sending the next data packet on the endpoint twice effectively gets the data toggle to the correct state. 12/18

13 upsd3400 USB firmware One such case where an endpoint's data toggle must be reset is after a Clear Feature/Stall request. How this is handled is dependent on the how the application code is structured. One such way is that when firmware determines that such a request was received, a transmit_again flag is set only if the current state of the toggle bit is a "1". If the toggle bit is a "0", it is in the correct state and nothing needs to be done. In the interrupt service routine for that endpoint, if the transmit_again flag is set, then the USIZE register should be written again with the packet size to rearm the FIFO. Since the FIFO contents remains unchanged after the data is sent to the host, the FIFO only needs to be armed again. (If different lengths of packets are sent on the endpoint, the packet size should be saved and written to the USIZE register in the ISR. If the same size packets are always sent on the endpoint, then this value may be hard-coded in the ISR.) The packet is sent with the next IN from the host, this time with the data toggle set to a "0". The code below is an example portion of the ISR for endpoint 1 processing. In this case, the packet size on the endpoint is always 0x40 bytes. If the packet size is variable, it is important to save the packet size in a temporary location so that USIZE is written with the correct length in the ISR for retransmission. if (UIF1 & IN1F) // EP1 IN UIF1 &= ~IN1F; USEL = INDIR SELEP1; UCON &= ~EPFIFO_BSY; if (transmit_again) //Rev A silicon only - check to see if packet should // be resent. This is to effectively clear the data // toggle. USIZE = 0x40; //Arm the FIFO to resend the packet. By resending the // packet, it gets the data toggle back to the correct // state. transmit_again = 0; //Reset the transmit again flag. // Processing of user data on EP USB interrupt service routine (ISR) framework All USB event-related interrupts vector to a single ISR. The order that the USB interrupt flags are checked and processed in the ISR determines the priority. The USB reset is a high priority event and should be processed first, especially since any pending USB interrupts are no longer valid when a USB reset is detected Treatment of USEL in the USB ISR - single FIFO usage If firmware uses the USEL register outside of the USB ISR, then USEL must be saved in a temporary variable when coming into the USB ISR and then restored before leaving the ISR. This is important as USEL may be changed while in the ISR resulting in the main line code accessing the wrong endpoint's register Treatment of USEL in the USB ISR - double FIFO usage If double FIFO (pairing) is used, the restore of USEL becomes a bit more complicated. With FIFO pairing, when USEL is read back and FIFO pairing is used on endpoint 1, USEL may 13/18

14 upsd3400 USB firmware AN2401 be a 1 or a 2 for the IN direction or 0x81 or 0x82 for the OUT direction. If it is a 1 or a 2, then USEL should be restored with a 1. If it is an 0x81 or 0x82, then it should be restored with an 0x81. When FIFO pairing is used on endpoint 3, if USEL is a 3 or a 4, then it should be restored with a 3. If USEL is an 0x83 or 0x84, then it should be restored with a 0x83. The framework for an example USB ISR is shown below. Note that temp_usel_saved is used to save and restore the USEL register. This example is for single FIFO operation. Figure 4. Example Framework for a USB ISR void UsbIsr(void) interrupt USB_VECTOR using 2 /****************************************************************************** Function : void UsbIsr() Parameters : none Description: USB interrupt service routine. ******************************************************************************/ unsigned char temp_usel_saved; // used to save and then restore USEL temp_usel_saved = USEL; // save USEL if (brstf) OnUsbReset(); // USB Reset int UCTL = VISIBLE; // enable USB FIFO mapping in XDATA /* OUT packets servicing */ if (boutf) if (UIF2 & OUT0F) // EP0 OUT if (USTA & SETUP) ReadSetupPacket() USTA &= ~SETUP; // Clear setup bit in USTA UIF2 &= ~OUT0F; OnSetupPacket(); else // Processing of user data on EP0 UIF2 &= ~OUT0F; if (UIF2 & OUT1F) // EP1 OUT UIF2 &= ~OUT1F; USEL = OUTDIR SELEP1; UCON &= ~EPFIFO_BSY; // Processing of user data on EP1 if (UIF2 & OUT2F) // EP2 OUT UIF2 &= ~OUT2F; USEL = OUTDIR SELEP2; UCON &= ~EPFIFO_BSY; // Processing of user data on EP2 if (UIF2 & OUT3F) // EP3 OUT UIF2 &= ~OUT3F; USEL = OUTDIR SELEP3; UCON &= ~EPFIFO_BSY; 14/18

15 upsd3400 USB firmware // Processing of user data on EP3 if (UIF2 & OUT4F) // EP4 OUT UIF2 &= ~OUT4F; USEL = OUTDIR SELEP4; UCON &= ~EPFIFO_BSY; // Processing of user data on EP4 /* IN packets servicing */ if (binf) if (UIF1 & IN0F) // EP0 IN UIF1 &= ~IN0F; TransmitEP0(); if (usbstate == US_ADDRESSED) UADDR = setuppacket.wvalue.lo; // new device address usbstate = US_DEFAULT; if (UIF1 & IN1F) // EP1 IN UIF1 &= ~IN1F; USEL = INDIR SELEP1; UCON &= ~EPFIFO_BSY; // Processing of user data on EP1 if (UIF1 & IN2F) // EP2 IN UIF1 &= ~IN2F; USEL = INDIR SELEP2; UCON &= ~EPFIFO_BSY; // Processing of user data on EP2 if (UIF1 & IN3F) // EP3 IN UIF1 &= ~IN3F; USEL = INDIR SELEP3; UCON &= ~EPFIFO_BSY; // Processing of user data on EP3 if (UIF1 & IN4F) // EP4 IN UIF1 &= ~IN4F; USEL = INDIR SELEP4; UCON &= ~EPFIFO_BSY; // Processing of user data on EP4 if (bsuspendf) if (bresumef) // If Resume interrupt occurred UIE0 = SUSPENDIE; // Enable the suspend interrupt UIE0 &= ~RESUMEIE; // Disable the resume interrupt OnUsbResume(); // Process the resume interrupt bresumef = 0; // Clear the resume interrupt flag bsuspendf = 0; // Clear the suspend interrupt flag 15/18

16 upsd3400 USB firmware AN2401 else // A suspend interrupt is detected UIE0 = RESUMEIE; // Enable the resume interrupt UIE0 &= ~SUSPENDIE; // Disable the suspend interrupt OnUsbSuspend(); // Process the suspend interrupt USEL = temp_usel_saved; // restore USEL Important Note: In single FIFO or double FIFO mode, an endpoint's busy bit should be cleared in the ISR when an interrupt was generated for that endpoint as a precaution against rare occurrences when the hardware does not properly clear the bit. The USB ISR framework shown in Figure 4 includes code that clears the busy bit for an endpoint when an interrupt event occurred on it. 16/18

17 Revision history 2 Revision history Table 1. Document revision history Date Revision Changes 20-Jul Initial release. 17/18

18 Please Read Carefully: Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries ( ST ) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any time, without notice. All ST products are sold pursuant to ST s terms and conditions of sale. Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no liability whatsoever relating to the choice, selection or use of the ST products and services described herein. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such third party products or services or any intellectual property contained therein. UNLESS OTHERWISE SET FORTH IN ST S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS EXPRESSLY APPROVED IN WRITING BY AN AUTHORIZED ST REPRESENTATIVE, ST PRODUCTS ARE NOT RECOMMENDED, AUTHORIZED OR WARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFE SUSTAINING APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS WHERE FAILURE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY, DEATH, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE. ST PRODUCTS WHICH ARE NOT SPECIFIED AS "AUTOMOTIVE GRADE" MAY ONLY BE USED IN AUTOMOTIVE APPLICATIONS AT USER S OWN RISK. Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any liability of ST. ST and the ST logo are trademarks or registered trademarks of ST in various countries. Information in this document supersedes and replaces all information previously supplied. The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners STMicroelectronics - All rights reserved STMicroelectronics group of companies Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan - Malaysia - Malta - Morocco - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America 18/18