Current Issue
Catch those Joules 4/6/2008
MORE BLOG POSTS
PCIM Europe | AT A GLANCE |
|
As a previous article (Reference 1) describes, USB’s designers originally intended their serial bus as a replacement for what are now legacy ports in today’s PCs. As a result, USB follows a master-slave model that assigns responsibility for overseeing data transfers to the PC host. A decade on from its inception, mass-market consumer electronics and USB’s popularity drive demand for a system that no longer requires a PC—for example, to make a direct connection between a digital camera in a cell phone and a photo-printer. Providing that devices always assume host or peripheral-device roles, it’s straightforward to embed a controller that fulfils that functionality. But how cater for arbitrary connections between devices that could be masters or slaves and relieve the user of knowing which is which? Enter USB On-The-Go (OTG), which extends the USB 2.0 specification with features specific to the task of interconnecting mobiledevices (see sidebar, “OTG Goes Onto the High Street”).
From a hardware-designer’s perspective, USB silicon consists of dedicated controllers or microcontroller peripherals. As a result, the major tasks are to ensure clean signal transitions that meet the system’s level and jitter specifications. You must also ensure that the power supply satisfies parameters such as inrush current. Yet you can’t self-certify USB hardware; you must either attend a free-for-members USB Implementer’s Forum compliance workshop (or “USB-IF plugfest”) or employ the services of a certified test house. Check the USB-IF’s website for thespecifications that dictate electrical tests and the necessary test equipment(Reference 2). As to the procedure,Cypress’ Application Note 023 providesa concise overview (Reference 3).
But when you’re starting off with any USB development, your first challenge is to understand the software processes that initiate and sustain communications between a host and a peripheral device. These processes are not trivial. Several semiconductor vendors offer development kits that ease this process, typically requiring only a PC to get up and running. Developers with real-world requirements will need a USB protocol analyser that allows independent message-exchange tracking. One example is the Ellisys USB Tracker, which Chris Stevens, managing director of embedded-tool specialist Computer Solutions, loaned here. For around €825, this entry-level device supports low-and full-speed analysis via two front-panel connectors that provide a loop-through connection for the system-under-test. A rear-panel connector communicates with a separate analysis PC that runs Ellisys’ Visual USB. This application records, filters, decodes, and presents data in multiple formats—visit Computer Solution’s website for an evaluation version that’s also useful as a training tool. If you connect a high-speed link, the Tracker won’t record, but it won’t disrupt traffic either (you can often force the system-undertest to full-speed operation by using the host PC’s mouse or keyboard USB ports). Alternatively, consider the Ellisys Explorer 200 (€2415), which decodeshigh-speed traffic.
EZ-USB ENABLES SOFT DEVICES
Promising rapid development of USB devices that you can entirely configure in software, the Cypress EZ-USB FX2LP development kit contains a target board, a plug-in breadboard, RS-232 and USB cables, and starter-kit and driver-development CDs. Documentation includes a “getting started” manual for EZ-USB, one for Keil’s Vision3 environment, and the EZ-USB technical reference manual. The installation process deposits documentation and examples such as driver firmware, hardware schematics, and PCBlayout information. The “getting started” material advises that you must have the full version of Keil Vision for the 8051as well as Visual C++ to compile the firmware examples and Windows code.In practice, the 4-kbyte-limited evaluationversion of Vision3 suits most ofthe kit’s examples, while Visual C++6.0 is necessary to develop your ownprograms, which may freely includeCypress’ CyApi class-library resources.The starter-kit CD also installs CypressGPIF Designer, a utility that providesa GUI (graphical user interface) tohelp develop waveform descriptors thatcontrol the proprietary GPIF (generalprogrammable-interface) hardware. Aseparate CD carries an evaluation copyof Jungo’s WinDriver development kitfor Cypress targets.
The target board’s major hardware components couple an FX2LP EZ-USB chip to 128 kbytes of SRAM, a pair of serial EEPROMs, and a PLD that generates chip-selects and debug-LED drive signals. Two I2C-port expanders scan user switches and drive a 7-segment display. The FX2LP device is the CY7C68013A-128C, which integrates a 48-MHz, four-clocks-per-instructioncycle 8051 microcontroller alongside the EZ-USB controller. Because the EZUSB logic implements the entire physical layer, it is capable of stand-alone operation in its basic mode and requires minimal intervention from the 8051 core or the GPIF hardware when running user applications. In typical use, the8051’s main USB tasks are to configure the interface and handle the high-levelprotocol by servicing host requests viacontrol-endpoint zero. The 8051 communicateswith the USB logic using aregister set in on-chip RAM; thereafter,the microcontroller is availablefor general-purpose use.
Alternatively, the GPIF hardware allows external hosts direct access to the EZ-USB engine’s FIFOs that support three fixed 64-byte endpoint buffers and 4 kbytes of buffer space that you can configure in twelve variations. Crucially, the GPIF includes all the logic that’s necessary for a glueless parallel connection to implement a single-chip USB interface to devices such as IDE hard disks, for which the target board carries an ATA header. Package options for the FX2LP include 56-pin SSOP and QFN, 100-pin TQFP, and the 128-pin TQFP that appears in the development kit. This last package breaks out all of its address and databus lines to enable use with the GPIF hardware. These lines also connect to an array of headers that mate with the plug-in breadboard. Depending on the package, you can access up to five I/O ports, two USARTs, three counter/timers, and eight interrupt-source extensions to the8051 interrupt structure.
Initially, it took two attempts to load the USB drivers for the XP Pro SP2 test machine, which then failed to illuminate the target board’s breakpoint/ monitor LED because the board arrived with its EEPROM Enable switch “off”. Without a valid external EEPROM, EZ-USB devices enumerate according to hardwired values that the technical reference manual describes. These values include Cypress VID (vendor-identification) codes that you must replace for production hardware (to apply for your own VID, see the USB-IF website). The Tracker protocol analyser confirms the connection sequence that the EZ-USB engine runs autonomously, with the Details pane decoding each part of every transfer (Figure 1). Alternatively, you can verify correct operation by checking Windows Device Manager fora Cypress USB-driver entry.
Uniquely, EZ-USB chips support ReNumeration, a two-step process that first enumerates according to conventionalhardwired device-descriptor exchanges. If the FX2LP discovers validcode in EEPROM, the chip then substitutesanother set of device descriptorsbefore simulating a disconnect/reconnectsequence by pulsing its D pullup.This causes the host to re-enumeratethe device and—if the appropriatescript is present—to download firmwareinto the FX2LP’s RAM. These featuresmake it easy to substitute your owndevice descriptors, distribute bug fixes,or implement wholesale configurationchanges entirely in software.
With monitor-based communications in process, the “getting started” guide suggests following the tutorial for the EZ-USB Interface application. Enabling operations from getting device descriptors to downloading programming data, this program provides a GUI for the target board. It adds FX2 device-specific toolbars but otherwise mirrors the underlying Cypress USB Console, a separate window into connected devices that match the company’s generic CyUsb.sys device driver (Figure 2). You can freely distribute and use this binary driver for your own projects, or contact Cypress for source-code licensing arrangements. Having confirmed correct operation by selecting the Get Dev button within EZ-USB Interface, the tutorial shows how to download and debug the dev_io code example using the Keil environment. This facility employs a serial connection to control execution and manage debug operations. The final tutorial loops back bulk data packets from two sets of endpoints within the FX2LP by setting up two input and two output pipes thateach buffer up to 64 bytes.
Most of the code examples use Cypress’ FrameWorks application-development software to build USB peripherals. FrameWorks simplifies tasks such as creating 8051 code to initialise the chip, handle USB-device requests, and control suspend power-management services. The user guide promises that all you have to do is provide a USB descriptor table and code to implement a basic peripheral, from which point you can build more sophisticated functionality. It would be really useful at this point if the guide provided a step-by-step example of how to accomplish this procedure. An example of creating an EZ-USB humaninterface- device appears on the website(Reference 4).
One method for confirming the necessary steps is to run the 30-day-limited Jungo WinDriver evaluation software. Bizarrely, I could not make even the simplest FX2LP WinDriver configuration compile, with the Keil compiler reporting that its size exceeds the evaluation limit by 247 bytes. This is unfortunate as WinDriver promises to accelerate driver development for both host and peripheral; it costs from $2,499 for a version that suits 32- or 64-bit Windows. But most Cypress examples compile without reaching the 4-kbyte limit—for instance, the dev_io sources that can serve as a template for developing your own code. Because this example doesn’t use FrameWorks, its actions are transparent save for the EZ-USB library calls that you can link into your own code. Thereare also several C++ examples, such as a simple console-based application thatdemonstrates access to the Cypress USBdriver via the CyApi class library. TheCY3684 EZ-USB FX2LP DevelopmentKit costs $495; upgrades to the full Keilenvironment are available from around€1,500.
MASS STORAGE MADE EASY
For around $99, Silicon Laboratories (SiLabs) offers development kits that suit its range of 8051-based mixedsignal microcontrollers. USB-enabled devices include the eight-member F34x series that the C8051F340DK kit supports. For another $99, SiLabs also offers a mass-storage-device reference kit to complement this kit. The basic F340 kit consists of a target board, USB-to-JTAG debug adapter, cabling, offline supply, and software CD. The development environment is again a 4-kbyte evaluation version of Keil’s Vision3. Assembly-language fans will appreciate the full version of Keil’s macro-assembler and linker for the 8051 that’s available from within the SiLabs IDE (integrated developoment environment). You can also install a stand-alone Flash programmer, the USBXpress environment that simplifies code development for SiLabs parts, andSiLab’s TCP/IP configuration wizard.
Within 10 minutes of opening the box, the single-sheet installation guide has you compiling and debugging your first example program. This code—which can serve as a development template—blinks a LED using a timer’s interrupt handler. It shouldn’t be unusual, but this process executed flawlessly. The CD again contains an evaluation version of Jungo’s WinDriver suite, together with a 3-task/5-event evaluation version of Pumpkin’s Salvo RTOS. Salvo subscriptions cost from around €600 per year for the LE version to around €1000 a year for the professional edition that bundles the sourcecode and code-configuration tools.
Inspecting the target board yields just three ICs—the C8051F340 microcontroller, a Sipex SP3223E RS-232 transceiver, and an LM2937 that regulates the 3.3-VDC supply. There’s the normal array of headers and jumpers, a reset and two user switches,and a potentiometer for stimulating the F340’s ADC. A 96-pin socket facilitatesconnection with expansion boards.The F340 core executes 70% of its8051 instruction set within two clockcycles to compute at peak rates of up to48 MIPS. It includes on-chip debuglogic that uses SiLab’s C2 two-wire interface.General-purpose on-chip resourcesinclude 64 kbytes of Flash and 4352bytes of RAM; up to 40 I/O lines; serialinterfaces that include two UARTs,SMbus/I2C, and enhanced SPI; four16-bit timers and a programmablecounter array; and a 10-bit, 200-kspsADC along with voltage reference,temperature sensor, and two analoguecomparators. A digital crossbar switchmaps internal resources to the 48-pinTQFP package’s I/O pins under programcontrol. Unusually, an 80-kHz oscillatorcomplements the master oscillatorthat’s calibrated to 12 MHz 180 kHzacross the chip’s operating range. Thehigh-frequency oscillator can serve as aclock source for the USB interface, orusers can supply an external clock.
Complete with an on-chip transceiver, the F340’s USB hardware supports low- and full-speed functions. A 1-kbyte RAM block provides the FIFO space that combines three pairs of in/out endpoints that feature up to 512-byte capacity with the bidirectional endpoint zero. The short but concise “getting started” guide describes a USB application example that uses interrupt transfers. It comprises three code sections—the host-resident driver, the target board’s firmware, and the host’s executable that displays the USBTest panel. The executable continually interrogates the target board to retrieve the temperature sensor’s reading and the ADC value that the potentiometer’s position determines. You can also read the pushbutton states, control theLEDs, and read/write port bits.
Crucially, the sources that implement this functionality appear in three subdirectories, along with instructions for tasks such as building the host’s driver using the Windows DDK (driverdevelopment kit). You will require a C++ compiler to modify the application code, specifically Microsoft Visual C++ 6.0. Although I’m no expert C++ programmer, my attempts at compilationusing the freely available Visual Studio Express Edition failed, primarilybecause Microsoft doesn’t include keyclass libraries from the earlier editionthat many programmers prefer to today’s.NET products. For anyone who doesn’thave Visual C++ 6.0, this may posea problem as the product is no longercommercially available.
If you have the correct environment and you set the C++ compiler’s project settings to “Debug Multithreaded”, the USB_Int project compiles flawlessly— otherwise expect error LNK2001: unresolved external symbol. Download the C8051F340 firmware from the SiLabs IDE, disconnect the debug adapter, and connect the target board’s USB port—then Windows should recognise the board (install the SiLabs driver if necessary at this point). If you then run or debug the newly compiled Windows executable, the USBTest panel appears and the host interrogates the board as before (Figure 3). Other useful exercises include examinations of the USB_Bulk and USB_HID application examples. By the time you will have explored them, you will thoroughly understand the structure ofa USB application.
The USB mass-storage-device reference- design kit attaches to the main board via the DIN41612 connector, breaking out address/data and SPI signals to the CompactFlash and SD/ MMC (secure digital/multimedia-card) connectors. The only active part on the expansion board is a MOSFET that powers the cards under program control. The kit includes a 256-kbyte SD/MMC memory card, an RS-232 cable, and a software CD. A precompiled application uses Windows HyperTerminal to run a command shell that controls the target boards via RS-232, logging events to and reading them back from the memory card. The firmware stores .txt-format files on the card using Windows FAT16 file structure. If you then plug in a USB cable, the target board disables the UART connection in favour of its USB port—whereupon the host PC registers the target boards as a removable disk, lists any files that you’ve recorded, and allows you to modify them just as any other text file. Similarly, removing the USB cable reconnects the UART and returns control to the serial terminal program. The firmware that’s necessary to accomplish this functionality appears in a subdirectory that the installer creates. As the object-file output approaches 90 kbytes, you will need the full Keil compiler to adapt or modify the source code that SiLabs’ Application Note 282 describes(Reference 5).
USB DEVELOPMENT LAB
By the time you read this, Maxim’s MAX3421E EVKIT-1 USB laboratory should be available from distributors including Digi-Key for around $58. Our sample consists of a 6575-mm board that carries two USB chips, eight pushbutton switches, and a 7-segment LED. The MAX3420E peripheral controller connects to one type-B receptacle, while the MAX3421E is a host/peripheral controller that’s wired to type-A and type-B connectors. A MAX4793 switch limits 5V power for the A-connector to 300 mA. You will also need Keil’s MCB2130 development kit for NXP’s LPC213x family, which the Maxim board plugs into via a header that Maxim thoughtfully provides. There’s also a short flying lead to supply 5V power for the A-port. This power can comefrom the Keil board or from a laboratory supply. A high-speed USB cable completesthe Maxim deliverables.
Also available from Digi-Key, the MCB2130 comes in two versions—a basic kit ($163.50) and one that includes Keil’s ULink USB-to-JTAG debug interface for the ARM7 ($337.50). The basic kit contains the target board, a USB cable, and Keil’s LPC2000 development- tool CD that installs an evaluation version of ARM’s RealView suite. The software includes a 16-kbyte-limited version of Vision3 for ARM targets. You can install a Flash programming utility that uses the COM port or use the ULink tool for this purpose. The base board’s major hardware components include the LPC2138 microcontroller, a MAX563 dual RS-232 transceiver, a 74LVC244 driver for eight LEDs, and an LM386 audio amplifier that drives a small loudspeaker. An LM1117 regulator derives 3.3V from the USB port’s 5V input. The board’s LPC2138—the topspecification member of the LPC213x family—embeds a massive 512 kbytes of Flash alongside 32 kbytes of RAM, two ADCs, and a DAC that complement the usual array of microcontroller peripherals.The package is a 64-pin LQFP.
On connecting a USB cable, the board bursts into life with metallic announcements from the speaker. Kill this noise by turning the potentiometer to zero while you get familiar with the MCB2130’s user guide, a help file on the CD. To confirm correct installation, compile and download a program example to Flash. Unusually, there is no board-specific quickstart guide, which requires you to navigate the help resources to unravel the correct set-up sequence. Avoid this problem by reading the Maxim documentation, which includes instructions for setting theenvironment (Reference 6).
NXP didn’t supply the ULink device that Keil has now discontinued in favour of the ULink2 that notably adds a realtime agent. This new facility allows you to trace states within a running program without halting it. The original ULink, which Segger makes, is similar to an RDI (remote-debugger-interface)-compatible Segger J-Link KS device that I had available. With the aid of the latest 3.66a version of the J-Link software and a temporary Flash programming license from Segger, I ran the JLinkRDIConfig. exe utility to configure the emulator before setting the Keil environment to operate via RDI. These steps made it possible to download and debug programs using the J-Link. Like the ULink, the device supports all the normal debug/trace facilities and allows you to set breakpoints in Flash. If you’re serious about developing applications on ARM targets, be sure to have this capabilityavailable (Reference 7).
Communications between the USB chips and the Keil board are via two SPI ports within the LPC2138’s ARM- 7TDMI core. Solder the header to Keil’s board, add the 5V flying lead, download Maxim’s documentation and a software file, and the system is ready to test. Or, that’s the theory—the version 3.31 Keilcompiler that the MCB2130 kit installed would not compile the Maxim sources,reporting “this evaluation version hasexpired”. Maxim’s documentation statesthat you must use the Keil mdk303a.exeinstall file as Maxim’s code links in twofiles from this environment. These fileswere available in v3.31 but presumablynot in the correct build version. Someswift support work from Trevor Martin,software engineer at Keil’s UK toolpartner Hitex, furnished mdk303a.exe(see Martin’s books that target NXP’sand ST’s ARM7 chips on Hitex UK’swebsite). The mdk303a.exe file installsKeil’s v3.34 toolchain that seamlesslycompiles and runs Maxim’s code. Theversion that currently appears on Keil’swebsite is mdk305.exe; this installsv3.51, which also works. Lane Hauck,senior scientist at Maxim, says that hiscompany is in the process of getting anagreement with Keil to distribute thekey startup.s and retarget.c files that theproject requires: “This should solve theproblem that file references may changefrom version to version,” he explains.
The demo example includes facilities such as a serial terminal console that reports device-enumeration data. The application serves as a development model for study and modification to suit your application’s needs. Implementing the peripheral device’s class as a standard human-interface device that emulates a keyboard avoids the requirement for a custom driver when connecting to a Windows PC; again, a protocol analyser is invaluable for users wishing to examine transactions. Maxim’s documentation—which is the model of clarity—describes the operation of each of the application’s major functions, including the host driver and its enumeration routine. As the ARM7 runs the host and device ports concurrently, it’s possible to connect the board’shost and device ports and retrieve the device’s descriptors (Figure 4).In this way, the system interrogatesitself and outputs the enumeration datato a PC over the serial terminal link.Furthermore, you can freely modify andredistribute code that you build usingMaxim’s examples.
YOU NEED MORE OPTIONS?
Other products that accelerate USB development include the latest in the Vinculum family of devices from FTDI, a company that long ago decided to bundle freely available firmware to promote its range of USB solutions. The new VDIP2 module carries two USB type-A sockets to interface with peripherals. Like its VDIP1 predecessor, this 40-pin DIP module relies on FTDI’s VNC1L device, which embeds a microcontroller capable of supporting USB host and most device classes. General- purpose resources include jumperselectable UART, parallel FIFO, and SPI interfaces. The module comes with Vinculum’s firmware that the core can download into on-chip Flash, with the disk and peripheral interface instruction set simplifying functions such as file anddirectory handling.
If you need to embody USB functions within an FPGA, consider QuickLogic’s ArcticLink family, which adds building blocks including high-speed OTGcapable USB 2.0 and SDIO to the programmable fabric (Figure 5). Optimised for mobile devices, these FPGAs also support the recent CE-ATA (consumerelectronics advanced-technology attachment) 1.1 interface, which combines the MMC electrical interface with a subset of the ATA hard-disk command set (see CE-ATA’s website for specifications). ArcticLink package choices comprise the 88-mm, 121-pin TFBGA that supports up to 60 I/Os and a 1212-mm version that doubles the possible I/O count. QuickLogic schedules full production for ArcticLink devices for the third quarter of 2007; the supporting development platform is currently in the late stages oftesting.
| OTG GOES ONTO THE HIGH STREET |
In producing USB-OTG (USB-on-the-Go), the developers closely follow USB 2.0 and introduce minimal changes (Reference A). Key differences include changes to speed and powerdistribution capabilities to suit battery sources. An OTG host must be able to communicate at USB 2.0’s 12-Mbps fullspeed rate, but the 1.5-Mbps low-speed and 480-Mbps high-speed abilities are optional— and, when in device mode, the 1.5-Mbps rate is no longer permissible. While PCs and conventional hubs supply a minimum of 100 mA of permanently connected 5V power, an OTG A-device must provide at least 8 mA of VBUS current and is allowed to disconnect this source during periods of inactivity. Devices that supply up to 100 mA must also be able to recognise under-voltage conditions; those that can supply more than 100 mA must abide by normal USB 2.0 specifi cations. Because the power level is typically limited, OTG devices must provide a list of compatible peripherals, as well as a means of informing users of invalid connections. Also, the capability to span external hubs is optional in an OTG system. Each OTG device must carry a single mini-AB connector. This is a receptacle that adds a fi fth ID (identifi cation) pin to the normal D, D, VBUS, and ground pins; an overall shield forms a sixth electrical connection. A mini-A plug grounds the ID pin, while a mini-B plug leaves it open or inserts a minimum 100 k to ground, allowing the device to recognise the type of plug that the user inserts (Figure A). The type of plug determines the device’s status as a power-sourcing A- or B-device load, and initially dictates the device’s role as host or peripheral, respectively. Accordingly, an OTG cable carries one mini-A and one mini-B plug. It’s also possible to connect a mini-A plug to a normal series-B USB connector to allow the OTG host to control a peripheral; similarly, a cable with a series-A plug that terminates in a mini-B connector allows a USB 2.0 host to control an OTG peripheral. Devices that can disconnect VBUS must support the SRP (sessionrequest protocol) that allows a B-device to ask a host to resume supplying power and start a new session, using one of two methods. Assuming that VBUS is low or out of its allowable range and the data lines are both low in the SE0 state for at least 2 msec, the B-device fi rst tries pulsing its D line by applying power to the speed-detection pull-up resistor for 5 to 10 msec. If this approach doesn’t succeed, the B-device tries the VBUS-pulsing method for an implementation- dependent period. This is the time necessary to charge the 2-to-13-F decoupling capacitance that’s present on an OTGto- OTG-device supply line above the 2.1V detection threshold from an 8-mA source. This same set of conditions must not drive the ~96 F minimum that a standard USB 2.0 host’s port mandates above 2.0V. To prevent any damage from a fast-acting Adevice driving current into the B-device, the specifi - cation suggests that the B-device drives VBUS from a voltage source of 3V with an output impedance of at least 281Ω. Perhaps OTG’s most interesting aspect lies within its HNP (hostnegotiation protocol) that supports dynamic host/device-mode allocation. This facility relieves users of the need to know which plug to insert into which OTG device. A device with a mini-A plug present at start-up assumes the host role and switches in USB 2.0-compliant pull-down resistors on D and D. The B-device switches a pull-up to the D line but keeps the D pull-down enabled to prevent the data line from fl oating if the cable disconnects. The A-device enumerates the B-device similarly to a USB 2.0 host but also examines the B-device’s OTG descriptor. This 3-byte entity reports HNP and SRP capabilities; only devices that can’t support peripherals are exempt from implementing HNP. Assuming that the B-device is HNPcapable, the A-device can then send a b_hnp_ enable code using the Set_Feature command, and suspend bus activity. On detecting bus suspension, the B-device requests the master role by setting the SE0 state. For high-speed operation, the B-device turns on its pull-up to D before turning it off; otherwise, the B-device simply disconnects its D pull-up. On detecting SE0, the A-device switches in its D pull-up to set the bus into the J-state, which causes the B-device to reset the bus. Now in master mode, the B-device can start enumerating the A-device and continue communications until it wishes to resume peripheral- mode operation. The B-device does so by suspending the bus, which the A-device detects. The latter then switches off its pull-up resistor or disconnects VBUS. The B-device also switches its pull-up to signify peripheral mode, so when VBUS is present, the Adevice detects the J-state and resets the bus. The A-device enumerates the B-device as before, and operation can continue in this confi guration, with each device setting its respective pull-up/pulldowns as necessary. REFERENCE “On-the-Go supplement to the USB 2.0 specification,” revision 1.2, April 2006, www.usb.org. |
CONTACT DETAI LS
You can reach Contributing Technical Editor David Marsh at forncett@btinternet.com.