Host Application Example - Freescale

August, 2010 

MQX USB Host Stack 

ENT-F0966 

K Muthukumar 

India University Program 

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, mobileGT, PowerQUICC, StarCore, and Symphony are trademarks of Freescale Semiconductor, Inc., 

Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, CoreNet, the Energy Efficient Solutions logo, Flexis, MXC, Platform in a Package, Processor Expert, QorIQ, QUICC Engine, SMARTMOS, TurboLink 

and VortiQa are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © 2010 Freescale Semiconductor, Inc. 

TM

►Agenda 

• Introduction 

• MQX USB HOST structure 

• Hardware layers 

� KHCI 

� EHCI 

• Data stack description 

� Data validation for HAL 

• Writing a new host application 

� Mandatory steps, 1 through 5 

� Additional steps 

� Services 



and VortiQa are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © 2010 Freescale Semiconductor, Inc. 2 

Agenda 

TM

►MQX USB Stack Features 

• Implements USB 2.0 version 

• Layered architecture 

� scalability (choose only components needed in application) 

� portability (class drivers independent on underlying hardware) 

• Class drivers supported: 

� Legacy MQX code 

– HID devices (mouse, keyboard) 

– MSD devices (flash disk) 

� Freescale MQX 

– HUB support (transparent communication through HUB) 

– CDC devices (serial communication) 




Introduction 

TM

HU 

B 

MFS 

MS 

D 

User Application 

Other to be 

developed 

HID CD 

C 

KHCI (Kirin2U/Kirin3specific 

controller) 

Intermediate 

I/O Drivers 

HOST API (class level) 

USB 2.0 Chapter 9 API 

Host Class 

Drivers 

OS and HW-level HOST API 

EHCI (Enhanced Host 

Controller Interface) 

USB Module (low-level drivers) 

Other (OHCI, ...) 




MQX USB Host Structure 

Hardware 

Independent 

Layer 

TM

►KHCI 




MQX USB Host Low-level Drivers 

• MCF522xx-specific USB controller (codename Kirin Host Controller) 

• Max. 10 Mbps (No support for high speed) 

• Physical transfer done by HW, DMA 

• Scheduling of transfers done by SW 

• USB transactions handled by SW 

• Requires separate task (khci_task), high CPU load 

• Does not handle any service (see later) 

►EHCI 

• Enhanced Host Controler Interface (industry standard) 

• ColdFire extends the specification (registers contain also bits that are 

not specified by EHCI standard) 

• Runs on interrupts / application requests 

• USB transactions handled by HW, DMA 

• Small CPU load 

TM

►KHCI Processing Example 1 

• USB Stack handles USB interrupt and notifies the main task (note that every seq. box 

means additional stack usage) 

KHC 

I ISR 

MQX lwevent 

KHC 

I 

TAS 

K 

USB 

H 

STA 

CK 

CLA 

SS 

DRV 

APP 

EVE 

NT 

APP 

TAS 

K 

MQX lwevent 




KHCI 

MQX ISR 

CONTEX 

T 

APP 

TASK 

CONTEX 

T 

KHCI 

TASK 

CONTEX 

T 

TM

►KHCI Processing Example 2 

• Application handles USB event, notifies main task and sends additional data to USB device 

(higher stack usage) 

KHC 

I ISR 

MQX lwevent 

KHC 

I 

TAS 

K 

USB 

H 

STA 

CK 

CLA 

SS 

DRV 

APP 

EVE 

NT 

CLA 

SS 

DRV 

USB 

H 

STA 

CK 

MQX lwevent 

KHC 

I 

FCN 

(e.g. next 

transfer) 




MQX 

lwevent 

APP 

TAS 

K 

KHC 

I 

TAS 

K 

KHCI 

MQX ISR 

CONTEX 

T 

APP 

TASK 

CONTEX 

T 

KHCI 

TASK 

CONTEX 

T 

TM

►EHCI Processing Example 1 

• Application handles USB event and then notifies main task 

EHCI 

ISR 

HAL CLA 

SS 

DRV 

APP 

EVE 

NT 

MQX lwevent 

APP 

TAS 

K 




EHCI 

MQX ISR 

CONTEX 

T 

APP 

TASK 

CONTEX 

T 

TM

►EHCI Processing Example 2 

• Application handles USB event, notifies main task and sends additional data to USB 

device (higher stack usage) 

EHCI 

ISR 

HAL CLA 

SS 

DRV 

APP 

EVE 

NT 

CLA 

SS 

DRV 

HAL 

EHCI 

FCN 

(e.g. next 

transfer) 

MQX lwevent 




APP 

TAS 

K 

EHCI 

MQX ISR 

CONTEX 

T 

APP 

TASK 

CONTEX 

T 

TM

► Writing host application, step 1 




Host Application Example 

• Clone one of the USB Host examples or create new project using 

MQX+USBHost stationery (MQX 3.3.0 or later). 

• Note that the usb_classes.h file is part of your application. 

• This file enables selected device enumeration and class drivers in the 

USB Host Stack. 

� Use USBCLASS_INC_XXX definitions to enable class for the device 

TM


• Specify event handlers for different types of devices. 

• Create array of USB_HOST_DRIVER_INFO structures. 





� In this example: all HID-BOOT keyboards connected to the host will be 

handled by usb_host_hid_keyboard_event 

TM






• Install low-level host driver using _usb_host_driver_install 

� Registers low-level HCI driver routines in the USB stack. 

� Low-level driver routines are prepared for each HCI (KHCI, EHCI, ..). 

� Allways use _bsp_usb_host_callback_table as an argument 

• Initialize host 

� Initializes host, prepares memory buffers and structures 

TM


• Register device classes in the USB host stack 

� Static class/handler table was prepared in step #2 





TM






• Write your device callback function (class event handler from step 2) 

• Four event types should handled in this function 

� USB_ATTACH_EVENT: called after device was attached 

� USB_CONFIG_EVENT: called after device was configured 

� USB_INTF_EVENT: called after device was interfaced 

� USB_DETACH_EVENT: called after device was detached 

• Enumeration, attach, detach and config events are processed by 

Chapter 9 sublayer of USB Stack. 

• No special actions are needed in the handler except: 

� Select interface with _usb_hostdev_select_interface after the 

ATTACH event (causes INTF event). 

� Remember actual state of the device together with handles for further 

processing in application. 

� After INTF event, application may communicate with the device using 

pipes. 

TM

► HID Keyboard Example 

• Handling ATTACH event: 

Event handler gets event 

code, device and interface 

handles 

We should remember the 

handles and the current 

state (for main application 

state machine) 

Selecting interface TBD 





TM


• Main task state machine 

When first interfaced, HID 

keyboard requires setting protocol. 

Note that we need to pass validation 

structure we obtained during interface 

select into HID class driver. 

Activating keyboard protocol. Note that this 

demo uses plain variable-based synchronization. 

(Rather should use lwevents) 





TM


• Communicating with keyboard 

Application obtains handle to 

communication pipe (in this case interrupt 

receive pipe). 

Receive transfer is initiated on the pipe, 

passing buffer pointer for data to be 

received. 

Waiting for interrupt transaction (Again: we 

should rather use lwevent-based 

synchronization) 



and VortiQa are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © 2010 Freescale Semiconductor, Inc. 


17 

TM

► Additional steps when writing host application 





• Always specific to application or USB device to be handled: 

� you may want to send control to endpoint zero 

� you may want to run interrupt pipe and handle the callbacks (interrupt request) 

� you may want to send / read data on bulk pipe 

� use class driver functions, host API functions to read / send data over pipes 

� register so-called service event handlers (_usb_host_register_service) or 

extend standard event handler (as shown in step 5) 

• Read MQX USB HOST API documentation for more details and 

API function description 

► Future MQX Development (Release 3.5, Dec/2009) 

• Create drivers to wrap most common standard functionality 

� Prepare Keyboard and Mouse I/O drivers 

� Wrap USB code needed to service Mass Storage Device 

� Wrap USB code needed to install virtual TTY device over CDC 

TM

Host Application Example - Freescale

Create successful ePaper yourself

Delete template?

Save as template?