Transcript Game Boy USB – Interface and Application

Game Boy USB – Interface
and Application
Robert Meerman
Introduction
•
•
•
•
•
•
•
•
•
•
Project Motivation & Focus
USB
Nintendo Game Boy Advance
Chips / Hardware
Enumeration
Descriptors, Requests & HID Class
Firmware
Unforeseen problems of note
Limitations and Restrictions
Demonstration preamble
Project Motivation & Focus
• To add connectivity to a Game Boy Advance, enabling it to
have PDA-like features.
• Essentially create a PC-to-GBA connection which is
– Widely compatible with current PCs (Serial? Parallel? USB?)
– Easy-to-setup (no drivers)
– Easy-to-use (no manual application configuration)
• Create a proof-of-concept application pair to demonstrate
the above by sending and receiving (raw) data.
• USB was chosen and implementing it became the focus of
the project.
USB Overview
• Universal Serial Bus had a fresh start, not backwards
compatible
• Benefits
– Automatic configuration, Hot pluggable, Bus powered
– 3 Speeds with max throughput of 53 MB/s, 1.2 MB/s & 800 kB/s
– Flexible for developers
• 4 Transfer types: Control, Interrupt, Bulk and Isochronous
• No specific functions for signals, unlike PC parallel port’s status lines
• (Composite) classes of device. E.g. mass-storage / printer / scanner
– Native operating system support
• Devices are micro-controlled and require firmware
• Problems with USB
– Legacy operating systems, Distance limits, no peer-to-peer.
USB Layers
• USB devices require a host, all terminology is from host’s perspective (IN / OUT)
• USB devices can have multiple configurations and/or interfaces per configuration
• Control Pipe always present, bi-directional, can be used for data
• Acknowledged (ACK), Not Acknowledged (NAK), Stall and Not Yet (NYET) tokens
Nintendo Game Boy Advance
• The Nintendo Game Boy Advance is a popular portable
games console. Some details include:
– 32bit ARM7TDMI CPU running on RISC architecture at 16.78Mhz
– 32KB of “internal” RAM and 256KB of “external” RAM
• 5-mode, multi-purpose communications port
– Normal, Multi-player & JoyBus – proprietary Nintendo protocols
– General Purpose – 4 pin I/O, using 0 / 3.3V signals
– Hardware UART – 1 byte buffer, interrupt capable, RTS / CTS
• Development
– Vibrant online community of successful hobbyists
– Plenty of tutorials & example and even a mature open-source IDE!
– Development of a UART “dumb terminal” was done quickly
Micro-controller
• The department have facilities for, and experience with,
Microchip-brand programmable PICmicro chips (“PICs”).
– Equipment / experience to write programs to chips and offer help
– CCS compiler, allows developing in C instead of assembly
• The PIC16F877 was recommended to me
– 33 I/O pins
– Likely sufficient Flash ROM (112,000 Bytes)
– Likely sufficient effective RAM (368 Bytes)
• Segmented memory
– RAM segmentation was not an issue as the CCS compiler
managed RAM memory
– ROM segmentation was an issue. The main interrupt handler had
to be broken up and a slight redesign made.
USB chip
• Common practice to have dedicated chip for signalling /
error correction / buffering USB communications
• Discovered source code + schematic based around a
PIC16F877 using a Philips Semiconductors PDIUSBD11
• Found further examples of D11 implementations
• D11 discontinued by Philips, replaced with PDIUSBD12
– 8bit parallel microcontroller interface, instead of I2C
– SoftConnect™, programmable internal 1.5kW pull-ups
– GoodLink™, LED indicator of USB status and traffic
• The D12 takes care of
– Communicating with bus (inc. retransmissions), notifying
microcontroller of (successful) events
• The PDIUSBD12 was decided upon.
Hardware
Descriptors & Requests
• Descriptors are data structures that enable the host to
learn about a device. E.g. Device descriptor includes:
–
–
–
–
–
USB Specification release number device complies with
Class code (Mass storage, Printer) and possible subclass code
Maximum packet size of control OUT endpoint (endpoint 0)
Vendor and product ID + device revision number
Indexes to string descriptor, number of configurations supported
• Other required descriptors:
– Configuration(s), Class, Interface(s), Endpoint(s)
• 11 standard requests (not all required), minimum set:
– Get_Descriptor
– Set_Address
– Set_Configuration
Enumeration
1.
2.
3.
4.
5.
6.
Device is attached, hub provides power & detects device
Hub does not talk to device yet, but informs host of event
Hub detects speed of device by looking at D+ / D- lines
Hub resets device, 10ms of logic low on both lines
Device is in “Default State” and answers to address 0x00
Host sends “Get_Descriptor” request, learns packet size
•
Windows asks for 64kB and issues a bus reset after first packet
7. Host assigns an address via “Set_Address”
•
Windows re-requests device descriptor, reads all of it
8. Host learns device’s abilities through successive requests
9. Host loads device driver
10. Device driver selects configuration
11. Enumeration complete, device available to user-mode
Human Interface Device (HID) class
• Needed to get PC side talking to hardware
• Human Interface Device (HID) class is intended for, but
not limited to, interacting with people.
– Data is exchanged in structured ‘reports’
– Low throughput (Max 24.576 MB/s, 64 kB/s and 800 B/s)
– HIDs use ‘interrupt’ transfer type. Not true interrupt, polled.
• Report structure defined in a report descriptor
• Report descriptors are compact, but also complex
• Multiple report structures can be defined, and can be
useful in saving bandwidth (send relevant data only)
Firmware
INT_N Low?
Y
N
Bus Reset?
Y
ReInitialise USB
N
Control OUT?
Y
Any marked data?
Y
N
Boundry finish?
N
Y
Y
Setup Token?
N
N
Control IN?
Expecting Report?
N
N
Send as much as
possible
Send zero-length
packet
Main OUT?
Y
Standard Request?
Y
Class Request?
N
Copy data to buffer
Y
N
Stall endpoint
Boundry finish?
Y
N
Any marked data?
N
Y
Send zero-length
Get_Report
Send Report Data
packet
Flag to expect data
Send as much as
possible
Set_Report
Update state
Set D12 address
Parse ROM data
Mark beginning / end
of data to be sent
Stall endpoint
Y
Match Found?
N
Y
N
Set_Configuration
Set_Address
Get_Descriptor
Y
Unforeseen problems of note
• Descriptors couldn’t be stored in PIC RAM due to space
limitations. Stored in ROM, separate data path. Parsing
approach, more readable and flexible than before!
• Debugging statements printed to dumb terminal take
milliseconds to be sent, which broke timing requirements
(Set_Address in particular), added DIP switches.
• RESET_N and CS_N (chip select) lines of D12 cannot
both be low at the same time, or the chip enters “test
mode” (Philips FAQ). Reset by firmware not possible.
Power push-button added.
• Undocumented D12 Set_Address behaviour. Address
must change after “status stage” of request (i.e. an ACK).
D12 buffers address and changes on next ACK, not
instantly. Discovered in USB-IF webboard.
Limitations of implementation
• Multi-transaction reports
– The firmware is unable to receive/send multi-transaction reports,
as a large enough internal buffer was not possible. Any test would
have to use fudged data. Code is in place, but cannot presently by
tested satisfactorily.
– Note that sending multi-transaction descriptors has been
implemented/tested and is core to the firmware.
• Get_Report
– Requests a report to be sent through the Control IN endpoint,
required by spec but not needed thus far, hence tricky to test.
Send correct data length, but data is all null. Believed to conflict
the Set_Report which is issued by the testing application
simultaneously
• Only tested on Windows. Only tested thoroughly with XP.
• Not suitable for transferring large amounts of data (bulk
transfers)
Demonstration Pre-Amble
• Project was successfully implemented to original (project)
specification: Driver-less, bi-directional transfers, no user
configuration required.
• Device fails in a compliant manner (Stalls endpoint)
• Two firmwares, both controlled from the GBA.
– HID Mouse. Offers instant feedback, was easiest to implement.
– HID Joystick. Mice / Keyboards are locked by the system, demo
app needed an unlocked device. Joystick still offers good
feedback using Control Panel’s “Game Controllers” panel.
• Will show data being captured by a user-mode application
• Will show data being sent from host to device, and
displayed on the GBA
• (Debugging log if time permits)
Debugging Log (time permitting)
CO DIR=I TO=D wV=0100 wI=0000 wL=0040 SREQ Get_Descriptor
GD(01) i=00(12, 01) Lo=00 Ll=12 DS
CI DS
BR
CO DIR=O TO=D wV=0004 wI=0000 wL=0000 SREQ Set_Address Z AS
CI ACK
CO [...] Get_Descriptor [...]
CI [...]
CO [...] Get_Descriptor [...]
CO DIR=O TO=D wV=0001 wI=0000 wL=0000 SREQ Set_Configuration
CI ACK
CO DIR=O TO=E wV=0000 wI=0082 wL=0000 SREQ Clear_Feature
CI S_CI ...