WinCE-BSP ARM-A8 User Guide

Introduction[edit]

Contents of this guide have been updated to include Release 2.30. Users of earlier releases can still use this guide but support for new platforms (AM387x and AM335x) is only available in Release 2.30.

This document provides information for the user of the Microsoft^® Windows^® Embedded CE 6.0 R3 BSP (BSP) or the Microsoft® Windows® Embedded Compact 7 BSP (BSP) for the Texas Instruments OMAP^TM35xx Evaluation Module (EVM), AM35xx Evaluation Module (EVM), AM387x EVM and AM335x General Purpose EVM. This combined offering is referred as "TI ARM_A8 BSP" in this document. Instructions are provided for installing the BSP, building images and loading images onto the EVM.

Requirements[edit]

There are many requirements for software, hardware, infrastructure and user experience level that should be met prior to working with EVM BSP and Windows CE.

Required Experience[edit]

This document is not intended for novice Windows CE users. Readers unfamiliar with Windows CE are encouraged to seek training and to study the documentation included with Windows CE before using the TI_ARM_A8 BSP and related documentation.

Required Software[edit]

The following software must be installed prior to installing the TI ARM_A8 BSP. Note that the software must be installed in the order listed. Contact Microsoft for more information about the listed software and known issues with the installation process: [ For BSP 1.x:

Visual Studio 2005 (VS2005)
Visual Studio SP1 (Service Pack 1)
Windows Embedded CE 6.0 (Plug In for Visual Studio 2005)
Windows CE 6.0 SP1 (Service Pack 1)
Windows CE 6.0 R2 Update
Windows CE 6.0 Cumulative Product Update Rollup Package 2009 (QFEs)
Windows CE 6.0 QFEs through November 2010

Users new to Windows Embedded CE6 can obtain evaluation versions of the required software from Microsoft http://msdn.microsoft.com/en-us/embedded/aa731407.aspx here.

For BSP 2.x

Microsoft Visual Studio 2008 Professional Edition
Microsoft Visual Studio 2008 Professional Service Pack 1
Windows Embedded Compact 7
Windows Embedded Compact 7 Updates - update 1 to update 4 (Oct 2011)

Required JTAG Tools[edit]

There are no JTAG tools required for use with above mentioned EVMs. Texas Instruments provides a tool that can be used to communicate with the internal boot ROM on the OMAP35xx processor called pserial. This tool can be used to program the bootloader into the EVM if there is no functional bootloader available.

Required Network Capabilities[edit]

The EVM supports communications with the development PC running Platform Builder using either Ethernet or USB RNDIS. Platform Builder requires the device to be on the same subnet as the development PC. The bootloader and kernel support both manual and dynamic IP address assignment. DHCP is enabled by default; this can be changed using the bootloader menu.

Notation Conventions[edit]

The following section describes terms used in this document.

CPU Name

This document is written to support a number of EVMs mentioned above. The term OMAP35xx will be used to indicate one of the CPU names (OMAP35xx family and AM/DM37x family) supported by the OMAP35xx EVM; AM35xx, AM387x and AM335x will be used to indicate one of the CPU names supported by their respective EVMs. When working with a particular CPU type, the term OMAP3530 should be understood as being the name of the CPU.

CPU family	EVM	Supported CPU name
OMAP35xx	OMAP35xx EVM	OMAP3503/3515/3525/3530
AM/DM37xx	OMAP35xx EVM	DM3730/3725, AM3715/3703
AM35xx	AM35xx EVM	AM3517/3505
AM387x	AM387x EVM (Baseboard only)	AM387x
AM335x	AM335x EVM (General Purpose, Profile 0)	AM335x

BSP Folder

This document is written to support the following EVMs:

OMAP35x EVM

AM35x EVM

AM387x EVM

AM335x EVM

The BSP folders for these EVMs are as follows:

OMAP35x EVM: platform/EVM_OMAP3530
AM35x EVM: platform/AM35X_BSP
AM387x EVM: platform/AM387x_BSP
AM335x EVM: platform/AM33x_BSP

In this document, the term BSP Folder will be used to refer to one of the above folders depending upon the context.

TI EVM

When not explicitly specified, TI EVM refers to any of the above mentioned EVMs.

OMAP35xx EVM also includes support for AM37x/DM37x processor family.

WINCE OS

When not explicitly specified, this content applies to both WinCE 6.0 R3 and WEC 7. For demonstration purposes, CE6 examples may be used. Unless otherwise specified in that section, similar principles apply for WEC 7 for those examples. Please use ARMV7 for CE7 and ARMV4I for CE6. When version number is not explicity mentioned, then 'Windows Embedded CE' and 'WinCE' terms refer to both WinCE 6.0 and WEC 7 in this document. When version number is not explicity mentioned, then 'Visual Studio' and 'VS' terms refer to both VS2005 and VS2008 in this document.

BSP Version

BSP 1.x releases are based on Windows Embedded CE 6.0 whereas BSP 2.x releases are based on Windows Embedded Compact 7.

Other Terms

Knowledge of Visual Studio, Platform Builder and Windows Embedded CE terms is assumed. The user should consult Platform Builder documentation for a definition of any unfamiliar terms.

BSP Features[edit]

This chapter discusses features of the TI ARM_A8 BSP.

Bootloader (EBOOT)[edit]

Bootloader and Initialization Sequence[edit]

The TI EVM board boots from Flash memory using the internal boot ROM of the TI ARM_A8 processor. The bootloader architecture consists of an initial bootstrap loader called the XLDR and a secondary loader called EBOOT. The internal boot ROM performs a minimum hardware setup, and then copies the XLDR from the first good block of Flash memory to a fixed location in internal SRAM. The boot ROM then jumps to the entry point of the XLDR.

The XLDR is a BSP specific bootstrap loader whose function is to do basic hardware initialization and copy the second stage, full featured EBOOT from Flash memory into RAM for execution. The XLDRsize is limited by the size of internal SRAM and does not implement any features other than what are needed for bootstrap.

Note: the BSP only builds the XLDR in Release configurations. Debug configurations use un-optimized code libraries that cause the XLDR to exceed the allotted size.

The primary development bootloader is called EBOOT. The primary purpose of the EBOOT loader is to load the operating system image from a specified source and launch it. EBOOT also provides a serial based user interface that allows a developer to control various aspects of the loader behavior.

Low Level Initialization[edit]

Low level hardware initialization is performed in the XLDR as part of its bootstrap requirements. This includes multifunction pin configuration, clock setup, chip select timings, and DDR configuration. The fileSRC\BOOTLOADER\XLDR\platform.c contains the routines responsible for initialization. This file must be modified for every hardware platform. The \INC directory contains a number of header files with defines that control many of the timing and memory map related initialization parameters.

Device Configuration Parameters[edit]

The bootloader provides user accessible configuration parameters that control various aspects of bootloader behavior. These parameters are primarily used during development to control where the OS image comes from, network configuration etc. Changes to the configuration parameters can optionally be saved to nonvolatile storage (Flash memory) and preserved across power cycles. The configuration parameters can be accessed by the user via the serial user interface.

For BSP 2.x releases, the configuration parameters can be saved and retrieved from flash even for SD bootloader. For AM335X and AM387X, instead of saving to NAND flash, you can select to save the configuration parameters to a binary file on SD card (eboot.cfg) by enabling the flag BSP_SAVE_EBOOTCFG_TO_SD in environment variable. This option is only available for SD bootloader.

Serial User Interface[edit]

EBOOT supports a user interface over the serial port exposed on the TI EVMs as shown in the following table through a RS232 connector.

EVM	Debug port on EVM	CPU UART
OMAP35x	main board::port3	UART3
AM35x	main board::port3	UART3
AM387x	main board::port0	UART0
AM335x	base board::port0	UART0

The actual physical CPU UART corresponding to this connector is configured to run with the following configuration:

115200 baud
8 data bits
1 stop bit
No parity

The UART3 connector is wired as a DTE device and requires a null modem cable to communicate with a terminal program on a Host PC.

Note: The available options on eboot menu depends on which eboot version is running (NAND, SD, etc)

Show Current Settings

This menu option provides a summary of the current bootloader configuration parameters. These include the current bootloader and OS kernel debug transport, device name, bootloader/kernel network configuration, and Ethernet MAC address.

Note: the settings shown are current values and have not necessarily been saved to nonvolatile storage. If modified configuration parameters are not manually saved to flash the changes are lost on a reboot.

Select Boot Device

This menu option configures the bootloader to load the OS image from the specified source. The options include downloading an OS image from Platform Builder over Ethernet (default), USB RNDIS, SD Card or loading the image from the OS partition on NAND Flash. The available choices depend on whether its SD or NAND version of EBOOT.

Select Debug Device

This menu option configures the KITL transport that will be used in a KITL enabled OS image. The options include Ethernet (default) or USB RNDIS.

Network Settings

This menu option configures various network settings used by the bootloader and kernel transports. It also includes a mechanism to program the MAC address into the EEPROM associated with the SMSC LAN9115 network controller (OMAP35x EVM).

On AM35x EVM, MAC address of Internal EMAC is obtained from read only register. When booting from NAND, this MAC address can be changed and saved in NAND.

On AM387x and AM33x EVM, MAC address of Internal EMAC is obtained from read only register.

The default network configuration uses DHCP, and therefore requires a DHCP server to be present on the subnet. Note that this network configuration applies only to bootloader and OS kernel KITL network communications. The regular Ethernet NDIS miniport driver has a completely independent configuration.

SDCard Settings

This menu option is only available with SD bootloader. This option allows you to change the kernel filename (default: nk.bin) that the bootloader should use to load the kernel.

Flash Management

This menu option provides a mechanism to manage the Flash memory on the EVM. Flash blocks can be reserved, erased, etc. These options are primarily available for diagnostic purposes and should not need to be used during development.

This menu also contains a mechanism to do a low level Flash format. The format operation partitions the non-reserved portions of Flash (area beyond the bootloader) into an OS partition and a file system partition. The size of the OS partition is fixed in a header file in the \SRC\INC directory.

The bootloader will automatically reformat the Flash during initialization if it detects that the partition does not exist or does not match the configured size (a new bootloader flashed with a changed OS partition size parameter).

Set Device ID

This menu option provides a mechanism to set the device ID. The device ID is used for various identification purposes. It serves as an input in creating the Universally Unique Identifier (UUID), creating a hardware entropy value etc.

Save Settings

This menu option provides a mechanism to save the current settings to nonvolatile storage. The settings will be retained across power cycles.

Note: For BSP 1.x releases, this option is not applicable when the system is booted from SD card. For BSP 2.x, when using SD bootloader, using this option results in saving of current settings to NAND flash.

For AM335X and AM387X BSP, users have the option to save the settings to a binary file on SD card instead of NAND flash. They need to enable the flag BSP_SAVE_EBOOTCFG_TO_SD in environment variable and re-build BSP. When the bootloader and kernel is built with this flag set, saving the settings is a 2 step process. In the first step, the user needs to select "Save Settings" from the eboot menu. The SD bootloader will not directly save the settings to the file but will appropriately set the OAL flag. Do not reboot the board but let the kernel boot-up. In this second step, the kernel on boot-up will recognize the OAL flag and will save the settings to the file on the SD card. Now if the user reboots the board, the settings would be retrieved and restored from the file on SD card (eboot.cfg). A small application <bsp>_ebootCfg.exe in the kernel does the magic of saving eboot settings to the SD card.

Enable/Disable OAL Retail Messages

This menu option enables/disables output of RetailMessages (strings printed using RETAILMSG() API) onto the serial port. This is used only for NON-KITL builds. For KITL builds, the retail messages are sent to the Platform builder window.

Select Display Resolution

This menu option lets the user select which display mode to use: LCD or DVI. Moreover, user can select the desired DVI resolution. The selected value is used by bootloader and the kernel to display content. This menu option eliminates the need for different bootloader/kernel for different display resolutions. This option is available only for OMAP35x and AM35x BSPs. AM33x BSP doesnt support multiple display resolutions except for the default (LCD 800x480). AM387X BSP provides compile time options via BSP catalog to change display resolutions.

Select OPP Mode

This menu option lets the user select the CPU frequency at which the kernel will run. This is same as "do opm" command but this doesnt require DVFS to be enabled in the kernel. This is a boot-time option available for OMAP35x, AM35x and AM335x BSP only. For OMAP35x and AM35x BSPs, to change the CPU frequency once the kernel is up and running, you will have to enable DVFS during build time and use "do opm" command as before. DVFS is not supported on AM335x and AM387x. Moreover, this option is not available for AM387X BSP.

NAND Flash Organization[edit]

The NAND Flash is divided into 3 regions: Reserved area (bootloader), OS partition, and file system partition. All regions start on NAND chip block boundaries.

Supported NAND chip[edit]

Please refer to EVM documentation to understand NAND chips populated on different platforms. Note that some versions of EVM hardware contain OneNAND flash and these devices have slightly different Flash geometry.

OMAP35xx EVM

The NAND chip is installed on Processor card of OMAP35xx EVM. The OMAP35xx BSP supports following NAND parts:

Manufacturer ID	Device ID	Nb of Blocks	Nb of Sectors per block	Sector Size	Bus width	Total Size
0x2C (Micron)	0xBA	2048	64	2048	x16	256 Mbytes
0x2C (Micron)	0xBC	4096	64	2048	x16	512 Mbytes
0xAD (Hynix)	0xBC	4096	64	2048	x16	512 Mbytes

AM35xx EVM

The AM35x BSP supports following NAND parts:

Manufacturer ID	Device ID	Nb of Blocks	Nb of Sectors per block	Sector Size	Bus width	Total Size
0x2C (Micron)	0xBA	2048	64	2048	x16	256 Mbytes
0x2C (Micron)	0xBC	4096	64	2048	x16	512 Mbytes

AM387x EVM

The AM387x BSP supports following NAND part:

Manufacturer ID	Device ID	Nb of Blocks	Nb of Sectors per block	Sector Size	Bus width	Total Size
0x2C (Micron)	0xCA	2048	64	2048	x16	256 Mbytes

AM335x EVM

The AM387x BSP supports following NAND part:

Manufacturer ID	Device ID	Nb of Blocks	Nb of Sectors per block	Sector Size	Bus width	Total Size
0x2C (Micron)	0xDA	2048	64	2048	x8	256 Mbytes

Reserved Area (Bootloader/Configuration Parameters)[edit]

The reserved area is located at the beginning of the NAND Flash and contains the XLDR, EBOOT, and configuration parameters. The size of the reserved area is dictated by the size of EBOOT and the requirements imposed on the XLDR by the internal boot ROM.

The internal boot ROM will attempt to load the XLDR from block 0. If an error occurs, the boot ROM will attempt to load from the next block up to a maximum of 4 blocks. This mechanism requires the XLDR to be located in each of the first 4 NAND blocks. For ease of implementation the BSP places the XLDR in the first four ===good ===blocks which could result in a copy of the XLDR being located beyond the first 4 physical blocks if a bad block is encountered. Note that the XLDR itself requires much less than a full block but the first four complete blocks are still used due to boot ROM requirements.

EBOOT is located in the blocks immediately following the last XLDR copy. Currently the EBOOT implementation requires 2 good blocks. Note that entire blocks must be reserved even though EBOOT may only require a small portion of the last block.

The configuration parameters are stored in the last page of the last EBOOT block; they do not take up an entire block themselves. The rest of the block containing EBOOT is saved and restored when the configuration parameters are updated.

The total number of blocks in the reserved area is the sum of the 4 XLDR blocks and the 2 EBOOT blocks, plus any bad blocks that are encountered in this region. Bad blocks are skipped and the next good block selected in the Flash algorithms.

NAND ECC support[edit]

There are 3 supported ECC modes by OMAP35x, AM35X BSPs: Hamming 1 bit ECC, BCH 4 bit ECC and BCH 8 bit ECC. ECC mode can be selected through Catalog.

Third Party \ BSP \ BSP:ARMV4I \ Drivers \ NAND \BCH 4 bit ECC
Third Party \ BSP \ BSP:ARMV4I \ Drivers \ NAND \BCH 8 bit ECC
Third Party \ BSP \ BSP:ARMV4I \ Drivers \ NAND \Hamming 1 bit ECC

Please Note that only the following chip revisions support BCH 4 bit correctly:

AM35x PG1.1 onwards
AM/DM37x PG1.1 onwards

AM387x and AM33x BSP supports only BCH 8 bit ECC with hardware error locator (ELM) mode.

ECC mode is determined from Eboot (compile time option), then the information is passed to Kernel. Before switching between different ECC modes, it is recommended to erase block 0-15.

OS Partition[edit]

The OS partition follows the reserved area and contains the OS image. This partition is created using the BOOTPART APIs. The partition is marked as a PART_BOOTSECTION indicating that it contains the operating system image. This partition type also prevents the Flash file system code from attempting to manage this area as part of its wear leveling algorithms.

The OS partition is created by the bootloader with a low level format during system initialization if it does not already exist. A low level format is also automatically performed if the bootloader detects an existing OS partition with a size different from what the bootloader expects. The OS partition size is set at compile time in the file\SRC\INC\image_cfg.h.

Note: A low level format destroys all data on the flash outside of the reserved area.

The Master Boot Record (MBR) is also created during the low level format and defined to be located in the first sector past the reserved area. Therefore it is located at the beginning of the OS partition. The Master Boot Record contains information describing the layout of the NAND flash to the Flash file system driver.

File System Partition[edit]

The File System partition takes up the remainder of the NAND flash. It is also created during the low level format operation in the bootloader. The File System partition is marked as a FAT partition and can be automatically mounted by the operating system.

OAL Features[edit]

This section provides a brief overview of some of the significant OAL features included in the TI BSP. The BSP implements a production-quality OAL. OAL reference information is available here.

Features[edit]

Summary

The OAL implementation includes support for the following SOC features and functionality:

Boot parameters (passed from boot-loader)
ARM cache (instruction and data, write buffer)
Interrupt controller (including GPIO interrupts)
Timer (1ms fixed system tick) – uses Timer 1 (Timer 3 for AM335X)
Real Time clock from external TPS65950 chip for OMAP35xx EVM
Real Time clock from external S35390 chip for AM35xx EVM
Real Time clock from internal on-chip module for AM335X and AM387X EVMs
MMU
System IO control
Kernel profiler – uses Timer 2
Serial debug support
KITL connection over Ethernet (interrupt or polled transport), and USB RNDIS
VMINI support
Library abstractions (GPIO, I2C, Clocks, Pad Configuration)
Watchdog Timer (WDT2)
Power management:
CPU idle support (ARM wait for interrupt in OEMIdle())
Low-Power suspend state

Boot parameters

When loading the kernel, a set of parameters are passed from the bootloader to the kernel for specific configuration. These parameters are defined under the BSP_ARGS structure which can be found under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\INC\args.h

This structure content is filled up by EBOOT at the address defined by IMAGE_SHARE_ARGS_CA located under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\INC\image_cfg.h

The kernel then reads this set of parameters for configuring the OAL and some features that are specific to the BSP.

Interrupt controller

<span style="color: teal"</span>The CPU’s interrupt controller is accessed by the OAL to provide interrupt management to other OAL libraries and device drivers. The CPU specific behavior of the interrupt management is located under:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI\OAL\OMAP_INTR

For AM335X CPU this code is located under:

<WINCEROOT>\platform\common\src\soc\COMMON_TI_V1\AM33X\OAL\INTR\

For AM387X CPU this code is located under:

<WINCEROOT>\platform\AM387X_BSP\SRC\oal\intr\

It provides interrupt management for on chip controllers and GPIO interrupts. Drivers can create Interrupt Service Routines using the OAL interrupt management following the guidelines described here.

Custom handling of interrupts that are specific to this platform is located under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\OAL\OALLIB\intr.c

System timer

The scheduling mechanism of the kernel is based on a system timer running at a fixed rate of 1 kHz. The OAL provides support for generating an interrupt every millisecond using an on chip General Purpose Timer. The source code used to provide this time base is located under:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI\OAL\OMAP_GTP_TIMER\TIMER\timer.c

The General Purpose Timer used as the system timer is defined at the BSP level in the BSPGetSysTimerDevice function located under:

<WINCEROOT>\PLATFORM\<BSP Folder>\\SRC\BSP_COMMON\BSPCFG\bspcfg.c

Real Time Clock

The device’s local time and date are referenced as "real time", which is generated by the onboard RTC chip. On OMAP35xx EVM, the RTC is inside TPS65950 companion chip is accessed via SPI. On AM35xx EVM, the RTC is sourced from on board S35390 chip. The AM335x and AM387x use internal on-chip RTC module. The time value is read from this chip whenever the OEMGetRealTime function is called by the system and is modified when the kernel calls OEMSetRealTime. At boot-up the OAL checks from the RTC if it has a valid value and then reads it to update the system’s time and date accordingly. If the RTC did not keep a valid value, which is mostly due to power shortage, then default time and date will be set.

The RTC is also responsible for generating interrupt on an alarm event. An application can for instance call the CeRunAppAtTime function to start a process at a given time. The RTC will be in charge of generating an interrupt at that given time for the kernel to run the specified application.

For AM35x, it is also possible to use the RTC as a wake up source for the suspend mode. This way one can put the platform to low power suspend mode and ask the RTC to generate an interrupt that will wake up the platform causing it to resume after a given amount of time. This behavior requires the BSP_RTC_WAKES_CPU variable to be set using the catalog item labeled "External RTC wake up".

For AM335x, RTC can be used as a wakeup source as well. See wiki on Power Management in SA.

The source code implementing the real time mechanism using the TPS65950 can be found under:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\TPS659XX\OALRTC\rtc.c

The source code implementing the real time mechanism using the S35390 chip can be found under:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI\OAL\S35390_OALRTC\oalrtc.c

The source code implementing the real time mechanism using on-chip AM335x and AM387x module can be found under:

<WINCEROOT>\platform\common\src\soc\COMMON_TI_V1\COMMON_TI_AMXX\OAL\OALRTC\oalrtc.c

Kernel Profiler

A high performance timer is needed by the kernel to generate Monte Carlo profiling logs. When profiling is on, an interrupt is generated at high frequency to observe the function being currently executed and provide statistics on the amount of time being spent in each function called during the profiling time. The General Purpose Timer used by the OMAP35x BSP to generate this interrupt is defined by the BSPGetGPTPerfDevice function under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BSP_COMMON\BSPCFG\bspcfg.c

Refer to the following article to learn how to use the kernel profiler:

Serial Debug Messages

The OAL uses the same serial port (CPU UART3) and configuration as the bootloader for serial debug messages. All debug messages are sent to the serial port if KITL is not enabled and if the "Enable/Disable OAL Retail Messages" option has been selected in EBOOT’s menu. When KITL is enabled some low level debug messages still appear on the serial port instead of over the KITL link. The regular serial driver must not be allowed to conflict with the debug serial port. The serial driver must be disabled for UART3 by unchecking the OS Design catalog item labeled "UART3 driver". However UART3 can be used a regular serial port driver if the OAL Retail messages have been disabled from EBOOT or if the OEMDeinitDebugSerial is called by the OAL.

NOTE: AM335x EVM and AM387x EVM uses UART1 as the debug serial port.

The serial debug port can be changed for another UART by changing the debugUartCfg structure inside:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BSP_COMMON\BSPCFG\bspcfg.c

Same rules as per UART3 apply if the serial debug port is changed to another UART.

KITL

The BSP supports debug connections to Platform Builder over Ethernet or USB RNDIS using the Kernel Independent Transport Layer (KITL). The KITL link allows Platform Builder to communicate with the device providing debug message services, kernel debugger support, target control, Release directory file system, and Remote Tools support. The desired KITL transport is selected via the serial bootloader menu.

The KITL link will be enabled when the KITL OS component is included in the image. This can be done in either debug or retail configuration by ensuring the IMGNOKITL environment variable is not set. It is important to note that if KITL is included in the image and active it requires a connection to Platform Builder running on the Host PC.

The network section of the bootloader serial menu provides an option to disable the KITL link even if the KITL component is included in the OS image. This allows the same image to support both KITL-enabled and regular builds. The user can decide at run time whether to activate the KITL connection or not. The KITL option is enabled by default so any image that includes KITL will attempt to connect to Platform Builder across the KITL link.

The KITL transports (Ethernet and USB RNDIS) are built directly into the OAL and are dedicated for use by the kernel. These transports do not use the regular NDIS miniport driver (in the case of Ethernet) or the USB Function controller driver (in the case of USB RNDIS). The regular driver must not be allowed to run simultaneously with the KITL transport or they will both contend for the same hardware resources. These drivers are automatically disabled when the KITL transport is used.

VMINI

The SMSC LAN9115 or Internal NDIS miniport driver is not permitted to load if the Ethernet KITL transport is in use for that respective port. In that case, the Ethernet port would not normally be available for application use. The Virtual Miniport (VMINI) driver provides a mechanism for applications to leverage the Ethernet KITL link by exposing an NDIS miniport driver interface to the KITL transport.

The network portion of the bootloader serial user interface provides a mechanism for the user to control VMINI. VMINI is enabled by default and will be available when KITL is active, but can be disabled if desired.

VMINI requires an active KITL link meaning there must be a connection to Platform Builder running on the host PC. However the VMINI architecture is otherwise transparent to the network stack and applications. It exists simply as a network miniport driver.

Library abstractions

The TI ARM_A8 BSP contains libraries providing abstraction to some widely used components such as GPIO, I2C, Clocks, and pad configuration. These libraries can be called from anywhere in the OAL and some of them are made available to drivers through the CEDDK.

GPIO

This library provides functions for configuring GPIOs and managing their related interrupts. In order to use them, one must call the GPIOOpen function to retrieve a handle prior to using the other functions.

The functions available in this library are defined under:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\INC\sdk_gpio.h

I2C

This library provides functions for communicating over the I2C bus. In order to use them, one must call the I2COpen function to retrieve a handle prior to using the other functions.

The functions available in this library are defined under:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\INC\sdk_i2c.h

Clocks

This library provides functions for managing controller’s clocks inside the CPU. All these functions require the device ID corresponding to the controller whose clock is to be configured. Device IDs are defined under the following header file: In OMAP35XX bsp:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\OMAP3530\INC\omap3530_clocks.h

In AM35XX bsp:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\AM3517\INC\am3517_clocks.h

In AM33x bsp:

<WINCEROOT>\platform\common\src\soc\COMMON_TI_V1\AM33X\inc\am33x_clocks.h

In AM387x bsp:

<WINCEROOT>\platform\common\src\soc\COMMON_TI_V1\AM387X\inc\am387x_clocks.h

The functions available in this library are defined under:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\INC\oal_clock.h

Pad Configuration

This library provides functions for configuring the pads of the CPU and selecting their multiplexing mode. These functions require one or an array of IDs and their associated configuration. The configurations of all the pads used by the TI ARM_A8 BSP are located at the BSP level under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\INC\bsp_padcfg.h

As these pads are multiplexing inputs from different controllers, it is important to keep the pad configuration centralized in one place to avoid conflicts. A reservation mechanism is implemented to decrease the risk of configuring the same pad from different places in the BSP. Each pad is reserved while being configured when calling the following functions:

RequestPad
RequestAndConfigurePad
RequestAndConfigurePadArray
RequestDevicePads

These functions will return FALSE if any of the pad requested has already been requested before. One must release a requested pad before being able to reconfigure this same pad. The following functions are used to release the pads:

ReleasePad
ReleasePadArray
ReleaseDevicePads

WARNING: It is mandatory to check the return value of these functions and act accordingly if it returns failure. Not checking successful return value before using the pad could lead to a conflict and unpredictable results.

This library contains functions (RequestDevicePads and ReleaseDevicePads) that request and configure pads based on a controller’s device ID. The device ID will be used to retrieve the controller’s associated pad array in bsp_padcfg.h and perform the request/configure mechanism on each of these pads.

The association between Pad ID arrays and controller’s device IDs is made in the following file:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BSP_COMMON\BSP_PADCFG\bsp_padcfg.c

WARNING: Be careful with the ConfigurePad function which does not request the pad prior to configuring it. It is used by the pad configuration internal mechanism and at some early stages of the OAL initialization. It should be used carefully and must not be called from the drivers.

The functions of this library can be found under:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\INC\sdk_padcfg.h

CEDDK

The CE Driver Development Kit is a dynamic link library that provides the drivers with a set of functions encapsulating common kernel calls to simplify the use of the kernel API. This feature is detailed here.

In the TI ARM_A8 BSP this DLL is customized to provide access to some of the OAL functions at the driver level. Most functions contained in the abstraction libraries described above are exposed to the drivers through the CEDDK. For a full list of these functions, refer to the following file:

<WINCEROOT>\WINCE600\PLATFORM\<BSP Folder>\SRC\DRIVERS\CEDDK\DLL\ceddk.def

Watchdog timer The TI ARM_A8 BSP has a watchdog timer used to automatically reset the CPU if not periodically refreshed by software, which happens in case of a software deadlock. The watchdog timer used for this purpose is defined by the BPSGetWatchdogDevice function located in:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BSP_COMMON\BSPCFG\bspcfg.c

For OMAP35x and AM35x BSP, the watchdog mechanism is implemented in the following OAL library:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI\OAL\OMAP_WATCHDOG\watchdog.c

For AM33x CPU the watchdog mechanism is implemented in:

<WINCEROOT>\platform\common\src\soc\COMMON_TI_V1\AM33X\OAL\WATCHDOG\watchdog.c

and for AM387X in:

<WINCEROOT>\platform\common\src\soc\COMMON_TI_V1\AM387X\OAL\WATCHDOG\watchdog.c

The watchdog feature is not enabled by default and can be added to the build by selecting the OsDesign catalog item labeled "Internal watchdog".

WARNING: Enabling internal watchdog in debug builds will most likely result in unexpected reboots during runtime. This feature should be used only on production builds.

Power Management

The OAL implements simple mechanisms to save power when no task is scheduled to run.

CPU Idle

The CPU idle mechanism provides the OEM with the ability of putting the CPU core in a low power state when no code is to be executed. The TI ARM_A8 BSP uses ARM’s "Wait For Interrupts" instruction to put the core to sleep while waiting for a scheduler interrupt to wake up the core and resume execution. This behavior is implemented into the OEMIdle function located in:

OMAP35x EVM and AM35x EVM:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI\OAL\OMAP_GTP_TIMER\TIMER\timer.c

AM335X EVM and AM387X EVM:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI_AMXX\OAL\TIMER\GPTIMER\timer.c

Low-power suspend state

OMAP35x EVM and AM35x EVM
Windows Embedded CE implements a suspend state where the whole platform is intended to be set to its lower power state while keeping RAM contents refreshed for fast recovery. The board can be put to suspend state using different means:

Calling the SetSystemPowerState function from an application or a driver
Clicking "Start" then "Suspend" from Windows CE’s desktop
Pressing the board’s power button (Only if item "Power key driver" is selected from the catalog)

Resuming from suspend state is done by configuring an interrupt as a wake-up source using the kernel IoControl named "IOCTL_HAL_ENABLE_WAKE". The TI ARM_A8 BSP comes with several drivers configured as wake-up sources:

Touchscreen driver(AM35x only)
Power key driver
RTC ("External RTC wake up" must be selected from the catalog)
SD card removal/plugin

The SOC specific code for implementing this feature is done in the OEMPowerOff function under:

For OMAP35xx EVM:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\OMAP3530\OAL\POWER\power.c

For AM35xx EVM:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\AM3517\OAL\POWER\power.c

AM335x EVM
For AM335X BSP, this feature is still under development and update on its status can be found here

AM387X EVM
This feature is not supported.

Build Options

Some build options and environment variables are available for enabling or disabling some features of the OAL:

Environment variable	Catalog Item/Build option	Effect
BSP_RTC_WAKES_CPU	External RTC wake up	Enables the ability for the RTC to wake the system up from suspend state after a specified amount of time. Available only on OMAP35x, AM35x and AM335x BSPs.
BSP_<bspName>_WATCHDOG	Internal watchdog	Enables the watchdog feature in the build. <bspName> can be OMAP, AM33X or AM387X depending on the BSP
IMGPROFILER	Enable Profiling(IMGPROFILER=1)	Enables MonteCarlo profiling in the build
IMGNOKITL	Enable KITL (no IMGNOKITL=1)	When set, this variable removes KITL from the build

Memory Configuration

The memory mapping of the runtime image is used to affect memory regions to a particular purpose. The memory configuration for each bootloaders and kernel binary can be configured from the following ".bib" files:

Xloader

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BOOTLOADER\XLDR\NAND\xldrnand.bib

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BOOTLOADER\XLDR\SDMEMORY\xldrsd.bib

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BOOTLOADER\XLDR\UART\xldruart.bib

EBOOT

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BOOTLOADER\EBOOT\NAND\ebootnand.bib

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\BOOTLOADER\EBOOT\SDMEMORY\ebootsd.bib

Kernel

<WINCEROOT>\WINCE600\PLATFORM\\<BSP Folder>\FILES\config.bib

This last "config.bib" file is also used to generate kernel builds meant to be stored in NAND flash. In order to generate such a build, set the IMGNAND environment variable.

TI ARM_A8 Common Drivers[edit]

This section provides an overview of the drivers included in the TI ARM_A8 BSP.

Display Driver[edit]

Supported features

The display driver supports the following features:

Windows GDI
DirectDraw
Hardware accelerated rotation using VRFB (only on OMAP35x, DM37x and AM35x platforms. Disabled by default but can be enabled with a catalog option)

The display driver supports LCD panel, DVI/HDMI output and TV out (s-video/composite) on the TI EVMs as shown in the following table:

EVM	LCD	DVI/HDMI	TVout
OMAP35x/DM37x	480x640	DVI	s-video/composite
AM35x	480x272	HDMI	s-video/composite
AM387x	No	HDMI	s-video
AM335x	800x480	No	No

OMAP35x EVM Display Modes (for OMAP35xx/DM37xx)[edit]

The display driver supports the following panels and resolutions:

Onboard LCD display - 640x480@60 Hz
External DVI display – 640x480@60 Hz
External DVI display – 640x480@72 Hz
External DVI display – 800x480@60 Hz
External DVI display – 800x600@60 Hz
External DVI display – 800x600@56 Hz
External DVI display – 1024x768@60 Hz
External DVI display – 1280x720@60 Hz

The panel/resolution to use is configurable through EBOOT’s menu item named "Select Display Resolution".

For LCD/DVI resolution of upto 800x600, TV out can be enabled in following ways:

1. At runtime, through "do tvout [on|off]" command

2. At compile time, through the catalog entries.

TV out display works in the following fashion:

1. When enabled, it duplicates the LCD/DVI desktop screen, provided the resolution is less than 800x600.

2. When enabled, if video playback is done using windows media player which uses overlays, then the video playback is seen both on LCD/DVI and TV out. Again the restriction is the clip should be less than D1 resolution

3. When enabled, if PowerVR/silverlight demos are run, then the outut is seen on both LCD/DVI and TV out.

4. If you dont want to duplicate the content on both LCD/DVI and TVout, then you will have to change the display driver (Hint: DetermineTVoutSurface())

5. If TVout is enabled and the default display driver behavior is assumed, then ISP resizer cannot be used to downscale the surfaces otherwise you may see green output on TV out. The reason being ISP resizer can do only one resizing at a time but when TV out is enabled, there are 2 surfaces that need to be resized (one for LCD/DVI and other for TV out). So your only option for resizing are to use DSS h/w resizer (already implemented in display driver) or software implementation. Note that DSS h/w resizer is restricted in its capability to downsize due to pixel clock. See TRM for more details.

AM35x eXperimenter board Display Modes[edit]

The display driver supports the following panels and resolutions:

Onboard LCD display - 480x272@60 Hz
External HDMI display – 640x480@60 Hz
External HDMI display – 640x480@72 Hz
External HDMI display – 800x480@60 Hz
External HDMI display – 800x600@60 Hz
External HDMI display – 800x600@56 Hz
External HDMI display – 1024x768@60 Hz
External HDMI display – 1280x720@60 Hz

The panel/resolution to use is configurable through EBOOT’s menu item named "Select Display Resolution".

AM335x GP EVM Display modes[edit]

The display driver supports the following panels and resolutions:

Onboard LCD display - 800x480@60 Hz

AM387x EVM Display modes[edit]

The display driver supports the following panels and resolutions:

External HDMI display – 1280x720@60 Hz (default)
External HDMI display – 1920x1080@30 Hz
External S-Video NTSC – 704x480@60 Hz
External S-Video PAL – 704x576@50 Hz

The display mode is compile time configured using catalog entries under Third Party->BSP->AM387X_BSP:ARMV7->Drivers->Display.

Registry entries

The registry entries for the display driver are located under:

AM335x BSP

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\DISPLAY\display.reg

OMAP35x, AM35x and AM387x BSP

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\DISPLAY\DSS\dss.reg

Key	Value	Description
Dll	omap_dss.dll am387x_display.dll am33x_display.dll	Dll of the driver in OMAP35x & AM35x BSP Dll of the driver in AM387x BSP Dll of the driver in AM335x BSP
IRQ	0x19	IRQ number of the DSS controller
Angle	0	Screen rotation angle (0=>0°,1=>90°,2=>180°) This feature is only available on OMAP35x and AM35x platforms
EnableNeonBlts	1	Use NEON for hardware accelerated blits
EnableWaitForVerticalBlank	1	Wait for Vsync is enabled for Overlay flipping
EnableOverlay	1	Enable Overlay in display driver; Only on OMAP35x and AM35x platforms, overlay is enabled.
HardwareRotation	1	Enable Hardware Rotation. Only on OMAP35x and AM35x platforms, rotation is enabled.
DMAFill	1	Enable Color Fill through DMA. Only on OMAP35x and AM35x platforms, DMAFill is enabled.
EnableDMABlts	1	Enable DMA Blts.

Limitations

No documented limitations.

Build options

The following build options can be added as environment variable to configure the display driver(only on OMAP35x and AM35x platforms):

Variable	Description
BSP_TVOUT_ENABLE	Enable display on TV output on bootup
BSP_OMAP_VRFB	Enable VRFB engine for Rotation

Driver API

The display driver follows the API required by the GWES framework and the DDGPE sample implementation.

This framework is documented at:

http://msdn.microsoft.com/en-us/library/aa921554.aspx

Example usage

Sample DirectDraw applications can be found under:

<WINCEROOT>\PUBLIC\DIRECTX\SDK\SAMPLES\DDRAW\SRC

GPIO Driver[edit]

Supported features

The OMAP35x EVM board comes with 192 on chip GPIOs and 18 GPIOs controlled by the TPS65950. The TPS65950 GPIOs are controlled through I2C and are able to generate interrupts to the CPU.

The AM35x Application/eXperimenter boards comes with 192 on chip GPIOs and 3 TCA6416 expander chips providing 16 GPIOs each. The GPIO expanders are controlled through I2C and are able to generate interrupts to the CPU.

The AM335X and AM387X SOCs have 128 on-chip GPIOs each.

The driver allows applications to configure GPIOs as inputs or outputs and read or write their states. The GPIO driver also exposes functions to enable or disable interrupt generation from a particular pin.

Registry entries

OMAP GPIO driver:

The registry entries for the CPU’s GPIO driver are located under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\GPIO\gpio.reg

Key	Value	Description
Dll	Omap_gpio.dll	DLL of the driver
Index	1	Index of the GPIO device
Order	0x00	Global order in which drivers are loaded

NOTE: DLL name for AM335X BSP is am33x_gpio.dll and name for AM387X BSPs is am387x_gpio.dll

The registry entries for the GPIO expander driver in OMAP35xx BSP are located under:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\ TPS659XX_GPIO \ tps659xx_gpio.reg

TPS65950 GPIO Expander:

Key	Value	Description
Dll	tps659xx_gpio.dll	DLL of the driver
Index	2	Index of the GPIO device
Order	0x00	Global order in which drivers are loaded

The registry entries for the GPIO expander driver in AM35xx BSP are located under:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\TCA6416_GPIO\tca6416_gpio.reg

GPIO Expander 1:

Key	Value	Description
Dll	tca6416_gpio.dll	DLL of the driver
Index	2	Index of the GPIO device
Order	0x00	Global order in which drivers are loaded
I2CBaudRateIndex	1	Index in the I2C baudrate table (1 => 400 kHz)
I2CBus	3	I2C Bus to use for accessing the expander
I2CAddress	0x20	I2C address of the expander on the bus
IntrGpio	0xA0	GPIO ID of the expander’s interrupt line

GPIO Expander 2:

Key	Value	Description
Dll	tca6416_gpio.dll	DLL of the driver
Index	3	Index of the GPIO device
Order	0x00	Global order in which drivers are loaded
I2CBaudRateIndex	1	Index in the I2C baudrate table (1 => 400 kHz)
I2CBus	3	I2C Bus to use for accessing the expander
I2CAddress	0x21	I2C address of the expander on the bus

GPIO Expander 3:

Key	Value	Description
Dll	tca6416_gpio.dll	DLL of the driver
Index	4	Index of the GPIO device
Order	0x00	Global order in which drivers are loaded
I2CBaudRateIndex	1	Index in the I2C baudrate table (1 => 400 kHz)
I2CBus	2	I2C Bus to use for accessing the expander
I2CAddress	0x21	I2C address of the expander on the bus

Limitations

No documented limitations.

Build options

No documented build Options.

Driver API

The best way to use GPIOs from drivers and applications is to use the GPIO library provided by the CEDDK. It provides abstraction to each GPIO driver using GPIO IDs defined for both onchip and external GPIOs.

This API is documented in the header below:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\INC\sdk_gpio.h

Function name	Description
GPIOOpen	Retrieve an handle on the GPIO driver
GPIOClose	Close the GPIO driver when done using
GPIOSetBit	Set the output to high level
GPIOClrBit	Set the output to low level
GPIOGetBit	Read the level of the input
GPIOSetMode	Configure GPIO mode
GPIOGetMode	Read GPIO mode
GPIOPullup	Enable/disable the pull-up on the GPIO
GPIOPulldown	Enable/disable the pull-down on the GPIO
GPIOInterruptInitialize	Hook up an interrupt event to the GPIO
GPIOInterruptMask	Mask/unmask the GPIO’s interrupt
GPIOInterruptDisable	Disable the interrupt event when no longer needed
GPIOInterruptDone	Function to call when done processing a GPIO interrupt
GPIOGetSystemIrq	Retrieve the IRQ number corresponding to a GPIO ID
GPIOInterruptWakeUp	Register the GPIO as a wake up source for the system

Example usage

Refer to the BSP specific part of the SDHC controller for a example on how to use GPIOs and processing interrupts:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\SDHC\impl\SDController.cpp

1-Wire/HDQ Driver[edit]

Supported features

The TI ARM_A8 BSP includes a 1-Wire/HDQ driver supporting the following protocols:

Benchmarq HDQ protocol
Dallas Semiconductor 1-Wire protocol

Registry entries

The registry entries for the 1-Wire/HDQ driver are defined in:

<WINCEROOT>\\PLATFORM\<BSP Folder>\SRC\DRIVERS\HDQ\omap_hdq.reg

Key	Value	Description
Dll	omap_hdq.dll	DLL of the driver
Order	9	Global order in which drivers are loaded
priority256	0x87	Priority of the Interrupt Service Thread

Limitations

No documented limitations.

Build options

No documented Build Options.

Driver API

The 1-Wire/HDQ driver follows a standard stream driver interface. Use the following function to use the driver:

Function name	Description
CreateFile	Retrieve an handle on the driver
WriteFile	Send data over the 1-Wire/HDQ bus
ReadFile	Read data from the 1-Wire/HDQ bus
CloseHandle	Close the driver’s handle when no longer needed

Example usage

No example usage of this driver is provided in the OMAP35x BSP.

McASP Support Library (AM387xx and AM33x Only)[edit]

McASP Features

Two independent clock generator modules for transmit and receive
Independent transmit and receive modules, each includes
- Programmable clock and frame sync generator
- TDM streams from 2 to 32, and 384 time slots
- Support for time slot sizes of 8, 12, 16, 20, 24, 28, and 32 bits
Wide variety of I2S and similar bit-stream format

Library Features

The BSP includes a library to support the use of the McASP peripherals. The library is linked with drivers that use McASP.

Limitations

No documented limitations.

Build Options

There are no build options for this library.

Library API

The McASP library API is defined in the follow header:

<WINCEROOT>\PLATFORM\COMMON\src\soc\COMMON_TI_V1\COMMON_TI_AMXX\MCASP\mcasp.h

The API is quite extensive and is not duplicated here. Refer to the McASP datasheet for the AM387x and AM33x for further information.

Example Usage

The AIC3106 Audio driver in the AM387x and AM33x BSP uses the McASP library. See the Audio driver section for more details.

McBSP Driver (OMAP35x and AM35x Only)[edit]

Supported features

The McBSP controller is a Multi-Channel Buffer Serial Port used to implement industry standard protocols such as PCM, TDM and I2S. The McBSP driver supports the 5 instances of the McBSP offering the following features:

Data transfers using DMA channels triggered on programmable FIFO thresholds
SIDETONE core support (McBSP2 and 3 only)
Full duplex communication
512 bytes buffer for McBSP1, 3, 4, 5
5K bytes buffer for McBSP2
4/6 pins configuration
Direct Interface to industry standard devices:
Inter-IC sound (I2S) compliant devices
Pulse code modulation (PCM) compliant devices
Time division multiplexed (TDM) compliant devices
Data size from 8 to 32 bits
Bit reordering
Clock and frame-synchronization generation support

Registry entries

The registry configuration of this driver can be found under:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\MCBSP\mcbsp.reg

The following registry keys have been defined for McBSP1. Refer to the registry file for default configuration of the other McBSP controllers.

Key	Value	Description
Dll	omap_mcbsp.dll	DLL of the driver
Order	0x13	Global order in which drivers are loaded
Port	1	McBSP controller instance
McBSPProfile	1	Mode : 0->I2S Slave, 1->I2S Master, 2-> TDM
DmaTxSyncMap	0x1F	SDMA Tx Channel ID
DmaRxSyncMap	0x20	SDMA Rx Channel ID
TxPriority	0x6E	Tx Thread priority
RxPriority	0x6E	Rx Thread priority
TxBufferSize	0x1000	Tx DMA Buffer size
RxBufferSize	0x1000	Rx DMA Buffer size
UseRegistryForMcbsp	1	Use default (0) or registry (1) settings
LoopbackMode	0	Enable/Disable loopback mode
WordsPerFrame	1	Number of words per frame (1-128)
WordLength	0x16	First Word length (8, 12, 16, 20, 24, 32)
WordLength2	0x16	Second Word length (8, 12, 16, 20, 24, 32)
ReverseModeTx	0	Transmit MSB first (0) or LSB first (1)
DataDelayTx	1	Number of bits to delay Tx frames (0, 1, 2)
ClockModeTx	1	Use internal (1) or external (0) Tx clock
FrameSyncSourceTx	3	Tx Frame Sync source : External (0), Internal(1), Generator(3)
PhaseTx	1	Tx Single (0) or Dual (1) phase
ClockPolarityTx	0	Tx Data driven on rising (0) or falling (1) edge
FrameSyncPolarityTx	0	Tx Frame sync is active high (0) or low (1)
FifoThresholdTx	0x7F	Tx fifo threshold before triggering DMA
ReverseModeRx	0	Receive MSB first (0) or LSB first (1)
DataDelayRx	1	Number of bits to delay Rx frames (0, 1, 2)
ClockModeRx	1	Use internal (1) or external (0) Rx clock
FrameSyncSourceRx	1	Rx Frame Sync source: External(0),Internal(1)
PhaseRx	1	Rx Single (0) or Dual (1) phase
ClockPolarityRx	1	Rx Data driven on rising (0) or falling (1) edge
FrameSyncPolarityRx	0	Rx Frame sync is active high (0) or low (1)
FifoThresholdRx	0x3F	Rx fifo threshold before triggering DMA
ClockSourceSrg	0	SRG source clock: rising CLKS (0), falling CLKS (1), CPU clock (2), CLKRI (3), CLKXI (4)
FrameWidthSrg	0x10	SRG Frame Width (1-256)
ClockDividerSrg	0x43	SRG Clock Divider (0-255)
ClockResyncSrg	0	Enable SRG source clock resynchronization
JustificationMode	0	Justify right zero fill (0), justify right sign fill (1), justify left (2)
TDMWordsPerFrame	1	Words per frame in TDM mode (1-128)
PartitionMode	0	TDM mode : 2-partition (0), 8-partition (1)
NumOfTxChannels	2	Number of Tx channels to enable
NumOfRxChannels	2	Number of Rx channels to enable

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

As the McBSP driver is entirely interrupt-driven, therefore its usage is based on callbacks provided by the calling driver.

The callbacks are passed to the McBSP driver using the following IoControls:

IoControl	Description
IOCTL_EXTERNAL_DRVR_REGISTER_TRANSFERCALLBACKS	Register callbacks by passing an EXTERNAL_DRVR_DATA_TRANSFER_IN structure. The IoControl returns a EXTERNAL_DRVR_DATA_TRANSFER_OUT structure containing callbacks that can be called by the driver to initiate Tx/Rx commands
IOCTL_EXTERNAL_DRVR_UNREGISTER_TRANSFERCALLBACKS	Unregister previously registered callbacks

The callbacks are defined as follows:

Callback name	Description
pfnInTxCommand	Pointer to a function called by the McBSP driver before issuing a Tx command
pfnInRxCommand	Pointer to a function called by the McBSP driver before issuing a Rx command
pfnInTxPopulateBuffer	Pointer to a function called by the McBSP driver for the calling driver to fill up the buffer to send
pfnInRxPopulateBuffer	Pointer to a function called by the McBSP driver for the calling driver to copy the received data
pfnMutexLock	Pointer to a function called by the McBSP driver to grab/release a critical section used throughout the calling driver
pfnOutRxCommand	Pointer to a function called by the calling driver to initiate a Rx command in the McBSP driver
pfnOutTxCommand	Pointer to a function called by the calling driver to initiate a Tx command in the McBSP driver

Example usage

The audio driver extensively uses the McBSP driver to exchange data with the codec over I2S. Refer to the audio driver for example usage:

<WINCEROOT>\PLATFORM \EVM_OMAP3530\SRC\DRIVERS\TPS659XX_WAVE

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\WAVEDEV2

SPI Driver[edit]

Supported features

The McSPI driver of the TI ARM_A8 BSP supports the following features:

McSPI controllers 1 to 4
Programmable word length from 4 to 32 bit
Master multi-channel mode (up to 4 channels)
Slave mode (Channel 0 only)
Two DMA requests per channel
64 bytes built-in FIFO per channel

Registry entries

The registry entries for configuring this driver can be edited from:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\MCSPI\mcspi.reg

These are defined as follows:

Key	Value	Description
Dll	omap_mcspi.dll	DLL of the driver
Order	8	Global order in which drivers are loaded
Port	1	Instance number of the McSPI controller
Timeout	0x300	Timeout value used in waiting loops

NOTE: The DLL name for AM335X BSP is am33x_mcspi.dll ans for AM387X BSP is am387x_mcspi.dll

<span style="color: teal"</span>Limitations

No documented limitations.

Build options

No documented build options.

Driver API

The McSPI driver comes with an SDK for easier use from the drivers and applications. The API of this SDK is documented in:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\INC\sdk_spi.h

The chart below gives a brief overview of the functions exposed by this SDK.

Function name	Description
SPIOpen	Open the driver and retrieve an handle
SPIClose	Close the driver when no longer used
SPILockController	Put the controller in single access mode
SPIUnlockController	Release the controller from single access mode
SPIEnableChannel	Enable one channel and assert the ChipSelect
SPIDisableChannel	Disable one channel and deassert the ChipSelect
SPIConfigure	Configure one SPI channel
SPISetSlaveMode	Put the controller in slave mode
SPIRead	Read data from the slave when configured in Rx only
SPIWrite	Write data to the slave when configured in Tx only
SPIWriteRead	Write/Read data from the slave
SPIAsyncWriteRead	Asynchronously Write/Read data from the slave
SPIWaitForAsyncWriteReadComplet	Returns when asynchronous transaction is complete

Example usage

The following sample code shows how to open the SPI driver and perform a read/write transaction over channel 0 on the bus.

#include <sdk_spi.h>   

DWORD  config;
HANDLE hSPI;
DWORD spiBuffer;

hSPI = SPIOpen(L“SPI1:”);
if (hSPI == NULL) 
{
        goto error;
}

config =   MCSPI_PHA_ODD_EDGES |
MCSPI_POL_ACTIVEHIGH |
                MCSPI_CHCONF_CLKD(5) |
                MCSPI_CSPOLARITY_ACTIVELOW |
                MCSPI_CHCONF_WL(32) |
                MCSPI_CHCONF_TRM_TXRX |
                MCSPI_CHCONF_DPE0;

if (!SPIConfigure(hSPI, 0, config)
{
        goto error;
}

spiBuffer = 0x80;
if (!SPIWriteRead(hSPI, sizeof(DWORD), &spiBuffer, &spiBuffer))
{
        goto error;
}

error:

if (hSPI != NULL)
{
	SPIClose(hSPI);
}

NAND Flash Driver[edit]

Supported features

The NAND Flash driver follows the FAL/FMD API such as described in the following article:

http://msdn.microsoft.com/en-us/library/ee482032.aspx

It exposes the NAND part as a block storage device that can be used by the Storage Manager to create and manipulate files using any supported file system. In addition, the NAND Flash driver supports bad block checking and ECC correction to avoid data corruption.

Registry entries

The registry entries for configuring the NAND Flash driver and its associated storage profile can be modified from:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\BLOCK\NAND\nand.reg

Key	Value	Description
Dll	omap_nand.dll am387x_nand.dll am33x_nand.dll	DLL of the driver
Order	4	Global order in which drivers are loaded
Profile	MSFlash (EC6) FlashDisk (EC7)	Storage profile to use on this storage device

Limitations

No documented limitations.

Build options

Variable	Description
IMGREGHIVE	Enable persistent storage on NAND device

Driver API

The FAL/FMD model requires the storage driver to implement a minimal set of functions. These functions are described below:

Function name	Description
FMD_Init	Perform the NAND part initialization
FMD_Deinit	Deinitialize the NAND Flash driver
FMD_GetInfo	Return the part’s physical geometry
FMD_ReadSector	Read one sector’s data and information
FMD_WriteSector	Write one sector’s data and/or information
FMD_EraseBlock	Erase one full block
FMD_GetBlockStatus	Return the status of one given block
FMD_SetBlockStatus	Writes the status of one block
FMD_PowerUp	Called when the platform resumes
FMD_PowerDown	Called when the platform goes to suspend mode
FMD_OEMIoControl	OEM custom IOCTL implementation

Example usage

As the Storage Manager handles all accesses to the NAND Flash driver, the user is only allowed to configure the storage profile that will be used on top of this driver. The following registry configuration shows how to automatically mount a FAT partition on top of the NAND Flash driver.

[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\FATFS]
    "Flags"=dword:14
    "MountAsBootable"=dword:1     
    "EnableWriteBack"=dword:1
    "FormatTFAT"=dword:1
IF IMGREGHIVE
    "MountAsRoot"=dword:1
    "MountPermanent"=dword:1     ; Do not allow un-mounting (else we'd fail to flush the registry)
    "MountAsROM"=dword:0
    "MountHidden"=dword:0
    "CheckForFormat"=dword:1     ; Ask the OAL if we should format on boot (i.e. cold reset)
ENDIF


[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash]
   "DriverPath"="Drivers\\BuiltIn\\MSFlash"
   "LoadFlags"=dword:1
IF IMGREGHIVE
   "BootPhase"=dword:1          ; Make NAND available in BootPhase1, to load the persisted registry
ELSE
   "BootPhase"=dword:0
ENDIF
   "Order"=dword:0
   "AutoMount"=dword:1
   "AutoPart"=dword:0
   "AutoFormat"=dword:0
   "DefaultFileSystem"="FATFS"
   "PartitionDriver"="mspart.dll"
   "Folder"="Mounted Volume"

NDIS SMSC9118 Driver[edit]

Supported features

The SMSC9118 driver is implemented following the NDIS specification detailed in the following article:

http://msdn.microsoft.com/en-us/library/ee486267.aspx

This driver exposes the onboard SMSC9118 chip as a network interface that can be accessed from the applicative level through the Winsock API. The EMAC controller supports the following features:

Synchronous 10/100 Mbit operation
Parallel interface with the CPU over the GPMC bus
Internal SRAM storing over 200 packets
DMA support
Integrated Ethernet MAC and PHY
16K byte FIFO memory
Automatic CRC generation and checking
Full/Half Duplex support

Registry entries

The registry entries related to the SMSC9118 driver are defined in the following file:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\SMSC9118\smsc9118.reg

The following chart sums up the applicable registry configuration for the SMSC9118 driver:

Key	Value	Description
DisplayName	SMSC11X Ethernet Driver	Name of the NDIS network interface
Group	NDIS	Class of the network driver
ImagePath	Smsc9118.dll	Name of the driver’s dll

Registry entries specific to the SMSC9118 driver are described below:

Key	Value	Description
SysIntr	0x10	Static SYSINTR assigned to the chip
IoBaseAddress	0x15000000	Physical base address on the GPMC bus
PhyAddress	0x20	PHY address (0x20=>auto,0xFF=>internal)
RxDMAMode	0	Rx Mode (1=>DMA, 0=>PIO)
TxDMAMode	0	Tx Mode (1=>DMA, 0=>PIO)
FlowControl	1	Flow control enabled (1) or disabled (0)
LinkMode	0x7F	ANEG/ASPAUSE/SPAUSE/100FD/100HD/10FD/10HD
AutoMdix	4	Auto Mdix controlled by strap
IntCfg	0	Value applied to HW_CFG_SRST(IRQ_POL/IRQ_TYP)

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

The SMSC9118 NDIS driver is accessed at the applicative level using the Windows Sockets API described at:

http://msdn.microsoft.com/en-us/library/aa917471.aspx

Example usage

No example usage provided for this driver.

Notification LED Driver[edit]

Supported features

The notification LED driver provides GWES with support for controlling onboard LEDs as user notifications. The notification LED driver follows the driver interface described in the following MSDN entry:

http://msdn.microsoft.com/en-us/library/ee481282.aspx

Registry entries

The registry entries retrieved by the notification LED driver can be found in the following file:

AM335x BSP:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\NLED\am33x_nled.reg

AM387x BSP:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\NLED\am387x_nled.reg'

OMAP35x and AM35x BSP:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\NLED\omap_nled.reg

It contains the following entries:

Key

Value

Description

Dll

omap_nled.dll

am33x_nled.dll

am387x_nled.dll

DLL of the driver for OMAP35x and AM35x BSP

DLL of the driver for AM335x BSP

DLL of the driver for AM387x BSP

Order

0x11

Global order in which drivers are loaded

Limitations

For DM37x NLED is not supported by default OSdesign due to conflict with Display driver.

Build options

No documented build options.

Driver API

The notification LED driver can be called through the following GWES API:

Function name	Description
NLedGetDeviceInfo	Return information on LED count, supported features and settings
NLedSetDevice	Changes settings of an NLED device

Example usage

The example use of this driver can be found in CETK NLED test code. The test code is available from Windows Embedded compact 7 installation:

<WINCEROOT>\PRIVATE\test\BaseOS\Drivers\LED\BVT\nledtest\tests.cpp

Power Management Driver[edit]

OMAP35X EVM and AM35X EVM

Supported features

The CPU comes with built-in features dedicated to saving power consumption when possible. The TI ARM_A8 BSP includes a power management extension that brings new power saving features such as Dynamic Voltage Frequency Scaling and Smart Reflex. The following features are handled by this power management driver:

Dynamic Voltage Frequency Scaling (DVFS): Allows the OPM - operating mode(the voltage/frequency pair) to be changed while the system is operating. On AM35x processor family, DVFS is not supported, since the voltage needs to be keep constant. However the Frequency can still be changed.
CPU load Policy: This power policy is configurable using registry entries and uses information about the CPU load (ratio of time the CPU spends running code as opposed to being in the CPU Idle State) to select a DVFS state for the CORE and MPU/IVA domains.
Device Monitor Policy: this power policy listens for device state change and tries to ensure the OPM stays high enough for the active devices to operate correctly.
Interrupt Latency: This driver provides the power manager with information regarding each driver’s expected interrupt latency. This adds constraints on the power manager to better decide which lowest power mode can be achieved depending on the drivers’ requirements.
System State Policy: this power policy provides constraints on the DVFS operating mode based on user activity.
Smart Reflex Policy: this policy uses information written into write once memory (EFUSE) in OMAP35x processors during factory testing. This information describes fine tuning that can be done to the OPMs. Smart Reflex is not supported in AM35x processors.

For more details, please refer to the following wiki page:

http://processors.wiki.ti.com/index.php/WinCE-TIBSP_Power_Management

Registry entries

The Power Management extension driver is configured through the registry keys defined in:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\PM\omap_pm.reg

DVFS:

Key	Value	Description
Dll	ti_constraintadapters.dll	DLL of the driver
Order	0x100	Global order in which drivers are loaded
Name	DVFS	Name of the DVFS driver
ConstraintClass	1	DVFS constraint class
OpmInit	4	Operating mode to be set at platform’s initialization
OpmFloor	1	Lowest operating mode to use on this platform
OpmCeiling	4	Highest operating mode to use on this platform
CORE1Map	"0","0","0","0","0"	Maps each CORE OPP to an associated OPM
MPU1Map	"0","1","2","3","4"	Maps each MPU OPP to an associated OPM

CPU Load:

Key	Value	Description
Dll	ti_cpuloadpolicy.dll	DLL of the driver
Order	0x999	Global order in which drivers are loaded
Name	CPULD	Name of the CPU load Policy
MonitorPeriod	0x1f4	Period of time in milliseconds driver uses to check CPU load
MonitorWindow	0x7d0	Periold of time in milliseconds driver uses to calculate(average) the current CPU load.
InterruptThreshold	0x41	cpu-load for sw interrupt- 65%
BootEventName	"Shell_Ready"	Highest operating mode to use on this platform
BootTimeout	0xea60	60 sec max wait for bootup
priority256	63	CPU load policy driver thread priority
CeilingOpm	4	Maximum OPM value
FloorOpm	0	Minimum OPM value
BootOpm	4	Initial OPM value
OpmFrequency	"12C","12C","258","320","3E8","0","0","0","0","0"	has one entry per operating mode in uppercase hex values, it is the supported frequency of each OPMs
OpmThreshold	"64","FA","1F4","2BC","3E8","0","0","0","0","0"	has one entry per operating mode in uppercase hex values, it is the threshold frequency of each OPMs

System State:

Key	Value	Description
Dll	ti_systemstatepolicy.dll	DLL of the driver
Order	0x999	Global order in which drivers are loaded
Name	SYSTEMSTATE	Name of the System State driver
UserOpm	2	opm = 2 for user active state
priority256	0x61	System state driver thread priority

Device Monitor:

Key	Value	Description
Dll	ti_policies.dll	DLL of the driver
Order	0x100	Global order in which drivers are loaded
Name	DEVMON	Name of the Device Monitor driver
SuspendState	0	One of the following value: LATENCY_STATE_CHIP_OFF 0, CORE+MPU+OTHER = OFF", LATENCY_STATE_CHIP_OSWR 1, CORE+OTHER = OSWR, MPU= CSWR", LATENCY_STATE_CHIP_CSWR 2, CORE+OTHER = CSWR, MPU = CSWR", LATENCY_STATE_CORE_CSWR 3, OTHER=OFF/OSWR/CSWR/INACTIVE, CORE = CSWR, MPU=CSWR", LATENCY_STATE_CORE_INACTIVE 4, OTHER=OFF/OSWR/CSWR/INACTIVE, CORE = INACTIVE, MPU=CSWR", LATENCY_STATE_MPU_INACTIVE 5, OTHER=OFF/OSWR/CSWR/INACTIVE, CORE+MPU = INACTIVE" CSWR = Clock Stopped With Retention OSWR = Off State With Retention

Interrupt Latency:

Key	Value	Description
Dll	ti_constraintadapters.dll	DLL of the driver
Order	0x100	Global order in which drivers are loaded
Name	INTRLAT	Name of the Interrupt latency driver
min	0	Minimum interrupt latency in ticks
max	0x7FFFFFFF	Maximum interrupt latency in ticks

Smart Reflex:

Key	Value	Description
Dll	ti_policies.dll	DLL of the driver
Order	0x999	Global order in which drivers are loaded
Name	SMARTREFLEX	Name of the Smart Reflex driver
SensingPeriod	0x3e8	Smart Reflex sensing time in milliseconds
SensingDelay	0x3e8	Smart Reflex sensing delay in milliseconds
LprOffOpm	2	Opm2

Limitations

AM35x processor family does not support Smart Reflex. It doesn’t support separate processor and core voltage domain and only has single core voltage domain VDD_CORE fixed at 1.2V. The max processor clock frequency derived from DPLL1 is 600MHz and can be reduced. Hence the DVFS in AM35x BSP only changes CPU operating frequency.

Smart Reflex driver can only be enabled when the Calibration data is available in EFUSE.

Build options

For BSP 1.x release, in AM35x BSP, the build options for various PM drivers are enabled in AM35x_BSP.bat

Variable	Description
BSP_NOPMEXT	Disable the Power management extension and all the associated features (DVFS,INTRLAT)
BSP_NODVFS	Disable Dynamic Frequency Voltage Scaling
BSP_NOINTRLAT	Disable Interrupt Latency module
BSP_NOCPUPOLICY	Disable CPU policies. Should not be disabled when DVFS is enabled.
BSP_NOSYSSTATEPOLICY	Disable System state policy driver
BSP_NOSMARTREFLEXPOLICY	Disable Smart Reflex policy driver

For BSP 1.x OMAP35x BSP and BSP 2.x (both OMAP35x and AM35x) releases, the build options for various PM drivers are enabled through Catalog, there is no documented build options.

Driver API

The power management driver is based on the Windows Embedded CE power management module such as described at:

http://msdn.microsoft.com/en-us/library/ee497722.aspx

The driver works standalone based on its configuration, however standard power management APIs can still be called with this extension enabled.

Example Usage

No example usage provided for this driver.

AM335X EVM and AM387X EVM
None of the PM policies and constraints (DVFS, SmartReflex, CPU load policy, etc) are supported in AM335X and AM387X BSPs. For power management support in AM335X, refer to the wiki here. In AM387X, only CPU idle is implemented. No other power management features are supported.

SDHC Driver[edit]

Supported features

The TI ARM_A8 SDHC driver supports the following features:

SD 2.0 compliant
SD High Capacity memory cards support
SDIO Host support
Write-protect support
2 SDHC controllers/slot

It has been written following the development concepts defined at:

http://msdn.microsoft.com/en-us/library/ee484829.aspx

It is based on the SDBUS2 driver provided since Windows Embedded CE 6.0 R2.

Registry entries

The registry entries for the SDHC driver as located under:

<WINCEROOT>\PLATFORM<BSP folder>\SRC\DRIVERS\SDHC\IMPL\sdhc.reg

The following chart details these entries:

Key	Value	Description
Dll	omap_sdhc.dll am33x_sdhc.dll am387x_sdhc.dll	DLL of the driver for OMAP35x and AM35x BSP DLL of the driver for AM335x BSP DLL of the driver for AM387x BSP
Order	0x21	Global order in which drivers are loaded
SDIOPriority	0xD3	Priority of the controller’s interrupt thread
CDPriority	0xD4	Priority of the change detection thread
BaseClockFrequency	0x16e3600	Max clock rate
ReadWriteTimeout	0x1000	Timeout value in clock ticks
DTOTimeout	0x200	Data timeout in milliseconds
WakeupSources	3	Wake the platform up on interrupt or change detect
CardDetectGPIO	0x100	GPIO number of the card detect pin (OMAP35x and AM35x BSP only)
CardInsertedState	0	Active state of the card detect pin
CardWPGPIO	0x3F	GPIO number of the write protect pin (OMAP35x and AM35x BSP only)
CardWriteProtectedState	1	Active state of the write protect pin
SlotNumber	1	Number of the SDHC controller instance
LowVoltageSlot	0	High 3.3V (0) or Low 1.8V voltage slot
Sdio4BitDisable	0	Enable(0) or disable(1) SDIO 4 bit support
SdMem4BitDisable	0	Enable(0) or disable(1) SDMEM 4 bit support

Limitations

On the AM35x EVM board, the "Card Detect" pin of SDHC slot 2 conflicts with the LCD’s "Power Enable" pin. Therefore Display driver and SDHC slot 2 cannot be used at the same time.

Build options

The following environment variables can be used at build time to configure the SDHC driver:

Variable	Description
MMCHSx_LOW_VOLTAGE	Use low voltage (1.8V) on slot x

Driver API

The SDHC is a bus driver and is therefore handled by the overlying client driver depending on the type of device plugged in. Thus the client driver will expose the proper API to the application to match the device’s purpose.

Example usage

No example usage is provided for this driver.

SDMA Driver[edit]

Supported features

This driver provides access to the onchip SDMA controller which supports the following features:

32 logical DMA channels
Transfer from/to memory/peripheral
8/16/32 but data element transfer size
Burst read and write
Up to 96 DMA requests
FIFO 256x32-bits wide

This driver is available on OMAP35x and AM35x BSPs.

Registry entries

The SDMA driver is configured through the registry entries located in:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\DMA\dma.reg

Key	Value	Description
Dll	omap_sdma.dll	DLL of the driver
Order	0	Global order in which drivers are loaded
Priority256	0x61	Priority of the SDMA interrupt thread

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

The SDMA driver is implemented as a standard stream driver exposing the following IoControls:

IoControl	Description
IOCTL_DMA_INTERRUPTDONE	Called when done processing a DMA interrupt
IOCTL_DMA_RESERVE_CHANNEL	Reserve/configure a DMA channel
IOCTL_DMA_RELEASE_CHANNEL	Release a previously reserved DMA channel
IOCTL_DMA_REGISTER_EVENTHANDLE	Register an event for being notified of DMA interrupts
IOCTL_DMA_DISABLESTANDBY	Disable Standby feature of the DMA controller
IOCTL_DMA_REQUEST_DEDICATED_INTERRUPT	Request a dedicated interrupt for a channel
IOCTL_DMA_RELEASE_DEDICATED_INTERRUPT	Release dedicated interrupt of a channel

Example usage

No example usage is provided with this driver.

EDMA Driver[edit]

Supported features

The EDMA driver is built around the TI EDMA3 Low Level Driver 01.10 (July 2009) package. The EDMA3 LLD code has been wrapped in a Windows CE streams interface driver that handles the CE specifics such as initialization and interrupt handling. This driver is available on AM387x and AM335x BSPs.

The EDMA3 LLD APIs are exposed for use by drivers and the CE EDMA driver adds a few additional APIs for event handling.

Registry Entries

The EDMA driver registry entries are defined in:

<WINCEROOT>\PLATFORM\<BSP Folder>\FILES\platform.reg

The registry entries are as follows.

Key	Value	Description
Dll	edmadrvr.dll	DLL into which the EDMA driver is built
Index	1	Identifies the EDMA driver instance for this set of entries
Order	1	Global order in which drivers are loaded (0 earliest). EDMA driver is used by other drivers so it is loaded early.
Flags	0	DEVFLAGS_xxx device flags
Priority256	0x46	IST thread priority

Limitations

No documented limitations.

Build Options

The EDMA region mapping registers is configured via this source file:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\EDMA\edma3cfg.c

The region mapping register configurations are towards the end of the file.

Driver API

The driver API is defined in the follow headers:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI_AMXX\EDMA\edma.h

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI_AMXX\EDMA\edma3_drv.h

Drivers should include the edma.h header.

The API is large and quite complex and is not reproduced here. See the comments in the header files and the EDMA datasheet for the SOC.

Example Usage

The EDMA test utility demonstrates how to use the driver interface to perform a simple memory to memory transfer:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\TEST\APPS\EDMATEST\edmatest.c

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\TEST\DRIVERS\EDMATEST\edma_test.c

Touchscreen Driver[edit]

Supported features

The TI ARM_A8 BSP touch screen driver follows the DDSI interface for implementing touch screen support into GWES. The touch screen driver reference is documented in the MSDN at:

http://msdn.microsoft.com/en-us/library/ee485627.aspx

The OMAP35x and AM35x Touch Screen driver implements low-level communication with the onboard TSC2046(for OMAP35xx EVM) and TSC2004(for AM35xx EVM) chip over SPI bus. It also implements sample filtering and averaging for better accurate measurement.

The AM335x Touch Screen driver configures the on-chip Touch screen controller and ADC to detect touch PEN UP/DOWN events and get coordinates. It implements a basic filtering and uses hardware averaging for better measurement.

[Update] The driver name in the bib and reg file is changed to touch.dll since transcriber looks for a dll with that particular name when launched.

Registry entries

The registry entries below are used to configure the TSC2046 touch screen driver:

WINCEROOT\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\TOUCH\tsc2046_touch.reg

Key	Value	Description
DriverName	touch.dll	DLL of the low-level part of the driver
MaxCalError	6	Maximum calibration errors allowed
PenGPIO	0xAF	ID of the PENIRQ GPIO
PenUpDebounceMS	0x28	PenUp debounce time in ms (0 to disable)
SampleRate		Number of samples per second to acquire
SPIBus	SPI1:	SPI bus used to access the TSC2046
SPIAddr	0	McSPI channel to use
InitialSamplesDropped	2	Number of samples to drop after pen detection

The registry entries below are used to configure the TSC2004 touch screen driver:

WINCEROOT\PLATFORM\AM35x_BSP\SRC\DRIVERS\TOUCH\tsc2004_touch.reg

Key	Value	Description
DriverName	tsc2004_touch.dll	DLL of the low-level part of the driver
MaxCalError	6	Maximum calibration errors allowed
PenGPIO	0x41	ID of the PENIRQ GPIO
SampleRate	0x6F	Number of samples per second to acquire
I2CBaudrateIndex	4	Baudrate index of the I2C bus (4 = 3.2 MHz)
I2CBus	1	I2C bus of the TSC2004 chip
I2CAddr	0x4B	I2C address of the TSC2004 chip

The registry entries below are used to configure the touch screen driver on AM335x:

WINCEROOT\PLATFORM\AM33x_BSP\SRC\DRIVERS\TOUCH\tsc_touch.reg

Key	Value	Description
DriverName	touch.dll	DLL of the low-level part of the driver
MaxCalError	6	Maximum calibration errors allowed
Wires	4	4-wires touch screen panel
SampleRate		Number of samples per second to acquire

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

The touch screen is exposed by GWES as a pointer device. No dedicated API is used for accessing the touch screen directly.

Example usage

No example usage is provided for this driver.

UART Driver[edit]

Supported features

The UART driver matches the serial driver requirements explained in the following article:

http://msdn.microsoft.com/en-us/library/ee483100.aspx

The on chip UART controller supports the following features:

4 UART controller instances (6 instances for AM335x and AM387x)
64-byte FIFO for receiver and 64-byte FIFO for transmitter
Programmable interrupt trigger levels for FIFOs
Baud rate generation from 300 bauds to 3,6 Mbauds
Hardware/software flow control
Data transmission over DMA (not supported on AM335x and AM387x)

The upper level of the UART driver is implemented in a custom library based on Microsoft’s "COM_MDD2", which is located at:

<WINCEROOT>\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\SERIAL\COM_MDD2

This custom library brings better support for advanced power management provided by the PMEXT driver.

Registry entries

The registry for the UART drivers is defined in:

<WINCEROOT>\PLATFORM\<BSP Folder>\SRC\DRIVERS\UART\uart.reg

Instance 1 of the UART controllers has the following configuration:

Key	Value	Description
Dll	omap_uart.dll	DLL of the driver
Order	9	Global order in which drivers are loaded
RxBuffer	0x2000	Rx hardware buffer size
TxDmaRequest	0xFFFFFFFF	Tx DMA request line (0xFFFFFFFF=>disable)
TxDmaBufferSize	0x2000	Tx DMA buffer size
RxDmaRequest	32	Rx DMA request line (0xFFFFFFFF=>disable)
RxDmaBufferSize	0x2000	Rx DMA buffer size
RtsCtsEnable	0	Enable RTC/CTS handshake support
HWMode	1	Use hardware auto RTC/CTS

Limitations

The UART driver for AM335X and AM387X does not support DMA.

Build options

No documented build options.

Driver API

The UART driver should be used from the applicative level using Windows Embedded CE’s standard serial communications functions detailed at:

http://msdn.microsoft.com/en-us/library/bb202722.aspx

Example usage

No example usage is provided for this driver.

USB Host Driver[edit]

Supported features

The USB Host driver is based on the EHCI controller of the CPU. It exposes the USB controller as a bus driver for USB client drivers to rely on. The EHCI driver supports the following features:

USB 2.0 standard compliant
Supports High Speed up to 480 Mbits/s
3 downstream ports available
Interface with ULPI PHY transceivers
USB Transceiver Less Link module

The driver is based on the EHCI MDD provided by Microsoft available at:

<WINCEROOT>\PUBLIC\COMMON\OAK\DRIVERS\USB\HCD\USB20\EHCI

Registry entries

The registry configuration file for the USB EHCI driver is located at:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\USBHS\omap_usbhs.reg

Key	Value	Description
Dll	omap_ehcihcd.dll	DLL of the driver
Order	0x46	Global order in which drivers are loaded
Port1Mode	0	Port 1 mode (0=>disabled,1=>PHY,2=>TLL)
Port2Mode	1	Port 2 mode (0=>disabled,1=>PHY,2=>TLL)
Port3Mode	0	Port 3 mode (0=>disabled,1=>PHY,2=>TLL)
Port1RstGpio	-	Reset pin of port 1’s PHY (if any)
Port2RstGpio	0x15	Reset pin of port 2’s PHY (if any)
Port3RstGpio	-	Reset pin of port 3’s PHY (if any)
Port1PwrGpio	-	Power enable pin of port 1’s PHY (if any)
Port2PwrGpio	0x16	Power enable pin of port 2’s PHY (if any)
Port3PwrGpio	-	Power enable pin of port 3’s PHY (if any)
Port1PwrLevel	-	Power enable pin active state of port 1’s PHY
Port2PwrLevel	1	Power enable pin active state of port 2’s PHY
Port3PwrLevel	-	Power enable pin active state of port 3’s PHY

Limitations

As the AM335x and AM387x SOCs do not have EHCI controller, this section is not applicable for them.

Build options

No documented build options.

Driver API

The USB Host EHCI driver is implemented as a bus driver. Therefore the API used to access the USB device is dependent on the implementation of the client driver.

Example usage

No example usage is provided for this driver.

USB OTG Driver[edit]

Supported features

The USB OTG driver brings the possibility of plugging both hosts and USB devices onto a single connector. The OTG mechanism will be in charge of loading the correct (Host/Device) driver accordingly.

It supports the features listed below:

Built around the Mentor USB 2.0 OTG core
Supports USB 2.0 peripherals at speeds up to 480 Mbits/s (HS)
Supports USB 2.0 Host at speeds HS (480 Mbits/s), FS (12 Mbits/s) and LS (1.5 Mbits/s)
Supports all modes of transfers (control, bulk, interrupt, isochronous)

The AM335x and AM387x have USB OTG subsystem with two ports. The AM335x EVM port 1 has micro usb connector and BSP configures this port to support the both host and device functionality. The port 2 has the host type connector and the OTG driver is configured to load the host driver only. The AM387x EVM has micro USB connectors on both ports. As the AM387x USB controller cannot do runtime ID pin detection, the USB ports statically configured as device only for the first port (USB0-OTG) and host only for the second port (USB1-OTG). The ID pin on USB1-OTG of AM387x EVM has to be grounded (Jumpers J23 and J26 needs to be shorted) to ensure that USB type A connection is detected while the board is powered up. Also the AM335x and AM387x USB subsytem has so called CPPI DMA controller, which is responsible to transfer USB packets between system memory and USB ports. There is only one CPPI DMA controller and it is shared by both ports.

The USB OTG driver comes in three different drivers: OTG, Host, and Device (AM335x and AM387x have additional cppi_dma driver). The OTG driver is based on the OTG MDD provided by Microsoft in the following directory:

<WINCEROOT>\PUBLIC\COMMON\OAK\DRIVERS\USBOTG

By default the OTG driver is the only one to be loaded at startup, it will then load the Host or Device driver upon detection of the plugged in connector.

Registry entries

The USB OTG driver is configured through the following registry files.

OTG Driver:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\MUSB\MUSBOTG\musbotg.reg

Key	Value	Description
Dll	omap_musbotg.dll	DLL of the driver
Order	0x63	Global order in which drivers are loaded
startupTimeout	0x1388	Waiting time at startup before timeout in ms
DisableHighSpeed	0	Disable High-Speed capacity (needed by some HUBs)
USBChargerHighCurrent	0x1F4	Number of milliamps when charging with high current
USBChargerLowCurrent	0x64	Number of milliamps when charging with low current
USBChargerNotify	vbus.power.event	Event to watch for charger notifications
vbusDischargeTime	0x50	Number of milliseconds to wait before checking VBUS level after suspend

USB Device Driver:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\MUSB\MUSBFN\musbfn.reg

Key	Value	Description
Dll	omap_musbfn.dll	DLL of the driver
Order	0x64	Global order in which drivers are loaded
EnableDMA	0	Enable/disable DMA transfers for packets
USBChargerNotify	vbus.power.event	Event to watch for charger notifications

USB Host Driver:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\MUSB\MUSBHCD\usbhcd.reg

Key	Value	Description
Dll	omap_musbhcd.dll	DLL of the driver
Order	0x65	Global order in which drivers are loaded
Dma	1	Enable/disable DMA transfers for packets
MaxCurrent	0x1F4	Max current in milliamps provided by the host

Note

Relevant registry files for AM335x and AM387X BSP are located at:

<WINCEROOT>\PLATFORM\AM33X_BSP\SRC\DRIVERS\USB\USBOTG\usbotg.reg
<WINCEROOT>\PLATFORM\AM33X_BSP\SRC\DRIVERS\USB\USBFN\usbfn.reg
<WINCEROOT>\PLATFORM\AM33X_BSP\SRC\DRIVERS\USB\USBH\usbh.reg
<WINCEROOT>\PLATFORM\AM33X_BSP\SRC\DRIVERS\USB\USBCDMA\usbcdma.reg
<WINCEROOT>\PLATFORM\AM387X_BSP\SRC\DRIVERS\USB\USBOTG\usbotg.reg
<WINCEROOT>\PLATFORM\AM387X_BSP\SRC\DRIVERS\USB\USBFN\usbfn.reg
<WINCEROOT>\PLATFORM\AM387X_BSP\SRC\DRIVERS\USB\USBH\usbh.reg
<WINCEROOT>\PLATFORM\AM387X_BSP\SRC\DRIVERS\USB\USBCDMA\usbcdma.reg

Limitations

The Mentor USB 2.0 OTG controller used in host mode does not support peripherals that do not comply with the USB 2.0 High Speed specification. In order to have such peripherals working on this OTG controller, one requires plugging it through a HUB that will perform the speed adaptation. Most regular USB 2.0 High Speed compliant HUBs should work.

Build options

No documented build options.

Driver API

No specific API is used to access the USB OTG driver as this one acts as a bus driver. The client drivers that are loaded depending on the device being plugged in will define the interface with the application layer.

Example usage

No example usage provided for this driver.

A Note about USB Audio[edit]

Wavplay with USB audio devices

The easiest way to test USB audio is to use Microsoft provided Wavplay application. However, this application uses default audio device to play audio and does not have any means to specify output device dynamically. In order to test USB Audio feature, you will have to modify the Wavplay sample application code to explicitly set an appropriate USB-audio device index. For the OS design that comes with the BSP, this index should be '1'.

The code for Wavplay application is located in public\common\sdk\samples\audio\wavplay\ directory. You cannot modify the code in the "public" location so you need to copy Wayplay code to your project directory and do the needed modification.

To set the desired device index you need to modify the PlayFile function in source file wavplay.cpp file by replacing WAVE_MAPPER by the "desired index" in the following line:

   mr = waveOutOpen(&hwo, 1, pwfx, (DWORD) hevDone, NULL, CALLBACK_EVENT);

Video input/Camera Driver[edit]

OMAP35x EVM and AM35x EVM

Supported features

The Video Input driver is based on the onboard TVP5146 chip that acquires video signals from various multiplexed sources then sends the video stream to the CPU over the ISP parallel bus. The Video Input driver exposes the video stream as a standard camera driver such as described at:

http://msdn.microsoft.com/en-us/library/ee485298.aspx

The Video Input driver is DirectShow compliant and supports the following acquisition sources:

Composite
S-Video
Component

The driver exposes the following formats:

PIN	Color format	Resolution	Bits Per Pixels	Frames per Second
CAPTURE/ PREVIEW	UYVY	704x480	16	30
CAPTURE/ PREVIEW	YUY2	704x480	16	30
CAPTURE/ PREVIEW	UYVY	720x480	16	30
CAPTURE/ PREVIEW	YUY2	720x480	16	30
CAPTURE/ PREVIEW	UYVY	352x240	16	30
CAPTURE/ PREVIEW	YUY2	352x240	16	30
CAPTURE/ PREVIEW	UYVY	176x120	16	30
CAPTURE/ PREVIEW	YUY2	176x120	16	30
CAPTURE/ PREVIEW	UYVY	704x576	16	25
CAPTURE/ PREVIEW	YUY2	704x576	16	25
CAPTURE/ PREVIEW	UYVY	720x576	16	25
CAPTURE/ PREVIEW	YUY2	720x576	16	25
CAPTURE/ PREVIEW	UYVY	352x288	16	25
CAPTURE/ PREVIEW	YUY2	352x288	16	25
CAPTURE/ PREVIEW	UYVY	176x144	16	25
CAPTURE/ PREVIEW	YUY2	176x144	16	25
CAPTURE/ PREVIEW	UYVY	604x480	16	30
CAPTURE/ PREVIEW	UYVY	320x240	16	30
CAPTURE/ PREVIEW	YUY2	640x480	16	30
CAPTURE/ PREVIEW	YUY2	320x240	16	30

Registry entries

The registry entries for the Video Input driver can be found in:

<WINCEROOT>\PLATFORM\<BSP>\SRC\DRIVERS\CAMERA\DLL\omap_camera.reg

Key	Value	Description
Dll	omap_camera.dll	DLL of the driver
Order	0x1000	Global order in which drivers are loaded

Limitations

Only interlaced input upto 480i is supported.

Build options

Variable	Description
ENABLE_DEINTERLACED_OUTPUT	Even and odd fields of interlaced input are combined in the frame buffer
ENABLE_YUY2	Enable support for YUY2 format
ENABLE_PAL	Enable support for PAL resolutions and frame rates

Note about AM35x EVM:

There are some changes in data line connection between TVP5146 and the AM35x CCDC module in recent version of application board (1015189 Rev C). In this newer version of app board, only 8 data lines are connected between TVP5146 and CCDC module. Hence the camera driver in BSP 01.02.00 and later is modified to use PACK8 structures to store captured samples to memory. If you are using older rev of application boards (ex: 1013690, 1014473), which has 10-bit data between TVP5146 and CCDC, then you will need to modify the %_WINCEROOT%\PLATFORM\AM35X_BSP\SRC\DRIVERS\VideoInputDrv\PDD\params.h (BSP 1.X) %_WINCEROOT%\PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1\COMMON_TI\PDD\params.h (BSP 2.x) to disable the macro ENABLE_PACK8. Rebuild the camera driver.

Driver API

The Video Input driver being DirectShow compatible, it can be accessed using the DirectShow API documented at:

http://msdn.microsoft.com/en-us/library/aa919874.aspx

Example usage

No example usage provided for this driver.

AM335X EVM and AM387X EVM
No camera driver support in available in AM335X and AM387X BSPs.

OMAP35xx EVM Specific Drivers[edit]

Audio Driver[edit]

Supported features

The audio driver is based on Microsoft’s "Unified Audio model" model and supports the TPS65950 as the external codec. More information on this audio model can be found at:

http://msdn.microsoft.com/en-US/library/ee483086.aspx

Following is the list of features supported by the codec and the driver:

2-channel output line, with dedicated 3.5 jack connector
1-channel input line, with dedicated 3.5 jack connector
Configurable input gain for each channel
Configurable output gain for each channel
Mute function for output line

The communication between the OMAP35x CPU and the TPS65950 codec is done through I2C for configuration and I2S for data communication. The OMAP35x CPU is responsible for configuring the codec through I2C to format the audio data that will be exchanged on the I2S bus.

Registry entries

The registry entries for the audio driver are located under:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\TPS659XX_WAVE\tps659xx_wave.reg

Key	Value	Description
Dll	tps659xx_wave.dll	DLL of the driver
Order	0x20	Global order in which drivers are loaded
ExternalPortDriver	MCP2:	Uses McBSP2 for I2S communication
StreamAttenMax	0x2C	Max attenuation (-44dB for Smartphone)
AudioProfile	0	I2S Slave->0, I2S Master->1, TDM Profile->2
NumOfPlayChannels	4	Number of playback channels
EnableAudioPlayChannels	"0","2","0","2"	Playback channels to enable
NumOfRecChannels	4	Number of record channels
EnableAudioRecChannels	"0","1","0","1"	Record channels to enable
DASFHwCodecAdpaterPath	hwcodecadapter.dll	DLL path of the Harware codec
AudioRoute	6	1 = Handset, 2 = Headset, 3 = Carkit (N/A), 4 = Speaker, 5 = BTHeadset (N/A), 6 = AuxHeadset
HwCodecInMainMicDigitalGain	0xF	15dB, controls TPS659XX ATXL1PGA register
HwCodecInMainMicAnalogGain	4	24dB, controls TPS659XX ANAMIC_GAIN register (L only)
HwCodecInSubMicDigitalGain	0xF	15dB, controls TPS659XX ATXR1PGA register
HwCodecInSubMicAnalogGain	4	24dB, controls TPS659XX ANAMIC_GAIN register (L only)
HwCodecInHeadsetMicDigitalGain	0xF	15dB, controls TPS659XX ATXL1PGA register
HwCodecInHeadsetMicAnalogGain	2	12dB, controls TPS659XX ANAMIC_GAIN register (L only)
HwCodecInHeadsetAuxDigitalGain	0xF	15dB, controls TPS659XX ATXL1PGA, TPS659XX ATXR1PGA registers
HwCodecInHeadsetAuxAnalogGain	0	0dB, controls TPS659XX ANAMIC_GAIN registers (L and R)
HwCodecOutStereoSpeakerDigitalGain	0xB5	12dB coarse gain and -53dB fine gain, controls TPS659XX ARXL2PGA and ARXR2PGA registers
HwCodecOutStereoSpeakerAnalogGain	0	12dB, controls TPS659XX ARXL2_APGA_CTL and ARXR2_APGA_CTL registers
HwCodecOutStereoHeadsetDigitalGain	0xBF	12dB coarse gain and 0dB fine gain, controls TPS659XX ARXL2PGA and ARXR2PGA registers
HwCodecOutStereoHeadsetAnalogGain	0	12dB, controls TPS659XX ARXL2_APGA_CTL and ARXR2_APGA_CTL registers
HwCodecOutHeadsetMicDigitalGain	0xAA	12dB coarse gain and -21dB fine gain, controls TPS659XX ARXL2PGA and TPS659XX ARXR2PGA registers
HwCodecOutHeadsetMicAnalogGain	0	12dB, controls TPS659XX ARXL2_APGA_CTL and ARXR2_APGA_CTL registers

Limitations

No documented limitations.

Build options

No build options.

Driver API

The audio driver follows the "Wave API" used by Windows Embedded CE. More information regarding this API can be found at:

http://msdn.microsoft.com/en-us/library/ee485233.aspx

Example usage

To use the examples below, you need to copy the following files from the flat release directory of your OsDesign to your board using any mean (ActiveSync, USB drive, FTP, SDCard, …):

wavplay.exe
wavrec.exe
wavmixer.exe (make sure that EVM_OMAP3530\SRC\APP\WAVMIXER is included in the build)

The following commands need to be launched from a command line window or using a Telnet connection.

Play a sound file:

wavplay <.wav file name>

Record sound from the line input during 5 seconds:

wavrec -f <output file name> -t 5000

Display the available mixer controls:

wavmixer –l

Record sound from line in for 3 seconds:

wavrec -f <output file name> -t 3000

Mute audio output:

wavmixer –s OUT 1 1

Unmute audio output:

wavmixer –s OUT 1 0

Keypad Driver[edit]

Supported features

The keypad driver provides a set of buttons mapped to virtual keys that are managed by GWES. The OMAP35x EVM board exposes 15 push buttons that are mapped to configurable actions triggered when the buttons are pushed. GWES provides the ability for the applications to hook up events on a virtual key. Therefore virtual keys are an abstraction of the physical buttons for better portability of the applications.

Registry entries

The registry entries for the keypad driver are defined in:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\ TPS659XX_KEYPAD \ tps659xx_keypad.reg

Key	Value	Description
Dll	tps659xx_keypad.dll	DLL of the driver
Order	0x21	Global order in which drivers are loaded
EnableOffKey	1	Pass VK_OFF to the OS
EnableWake	1	Register the keypad as a system wake up source

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

The keypad driver follows the standard Keyboard API that is used by GWES’ input manager. More information on Keyboard drivers can be found at:

http://msdn.microsoft.com/en-us/library/ee486116.aspx

By default, the keypad driver implements the following mapping:

Physical Button	Virtual Key
S4	VK_ESCAPE
S5	VK_TAB
S6	VK_THOME
S7	VK_TSOFT1
S10	VK_TSOFT2
S11	VK_TLEFT
S12	VK_SPACE
S13	VK_TUP
S15	VK_TDOWN
S16	VK_TBACK
S17	VK_TRIGHT
S18	VK_TACTION

This mapping can be modified from the file below:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\TPS659XX_KEYPAD\vk_map.c

Example usage

The Windows Embedded CE Media Player takes advantage of the keypad driver using GWES framework. Refer to the ceplayer source code located under:

<WINCEROOT>\PUBLIC\DIRECTX\SDK\SAMPLES\WMP\CEPLAYER

Power Key Driver[edit]

Supported features

The power key driver allows the user to put the platform to suspend by pressing the PWR_ON button from the keypad during a minimum amount of time.

Registry entries

The keypad driver exposes its registry entries in the following file:

<WINCEROOT>\PLATFORM\EVM_OMAP3530\SRC\DRIVERS\ TPS659XX_PWRKEY \ tps659xx_pwrkey.reg

Key	Value	Description
Dll	tps659xx _pwrkey.dll	DLL of the driver
Order	0x21	Global order in which drivers are loaded

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

This power key driver does not expose any API. It is a standalone driver that is functional as soon as it is loaded at startup.

Example usage

Press the power button (labeled "PWR_ON) for more than one second and the platform will go to suspend mode.

AM35xx EVM Specific Drivers[edit]

Audio Driver[edit]

Supported features

The audio driver is based on Microsoft’s "WAVEDEV2" driver model and supports Texas Instruments’ AIC23 codec only. More information on the WAVEDEV2 audio model can be found at:

http://msdn.microsoft.com/en-us/library/ee485290.aspx

Following is the list of features supported by the codec and the driver:

2-channel output line, with dedicated 3.5 jack connector
2-channel input line, with dedicated 3.5 jack connector
Microphone input, with dedicated 3.5 jack connector
Configurable input gain for each channel
Configurable output gain for each channel
+20 dB boost for microphone input
Mute function for output line

The AM35x Application board embeds two different AIC23 chips with a dedicated set of connectors for each codec. Note that Codec 2 does not have a "Line In" connector wired up.

The communication between the AM35x CPU and the AIC23 codecs is done through I2C for configuration and I2S for data communication. The AM35x CPU is responsible for configuring the codec through I2C to format the audio data that will be exchanged on the I2S bus.

Both codecs can be simultaneously added in the build. If only one codec is included, it will be considered as the primary sound device by the Wave API. If both of them are loaded at runtime, then Codec 2 will be the primary sound device. Codec 1 is still usable by passing its ID as the "uDeviceID" parameter to the "waveOutOpen" function. Follow this link for more details on this function:

http://msdn.microsoft.com/en-us/library/aa910393.aspx

Registry entries

The registry entries for the audio driver are located under:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\WAVEDEV2\omap_wavedev2.reg

Codec 1:

Key	Value	Description
Dll	omap_wavedev2.dll	DLL of the driver
Order	0x20	Global order in which drivers are loaded
PortDriver	MCP1:	Uses McBSP1 for I2S communication
I2CBaudRateIndex	1	Index in the I2C baudrate table (1 => 400 kHz)
I2CBus	2	I2C Bus to use for configuring the codec
I2CAddress	0x1A	I2C address of the codec on the bus

Codec 2:

Key	Value	Description
Dll	omap_wavedev2.dll	DLL of the driver
Order	0x20	Global order in which drivers are loaded
PortDriver	MCP2:	Uses McBSP2 for I2S communication
I2CBaudRateIndex	1	Index in the I2C baudrate table (1 => 400 kHz)
I2CBus	2	I2C Bus to use for configuring the codec
I2CAddress	0x1B	I2C address of the codec on the bus

Limitations

The AIC23 codec is configured as an I2S slave by default whereas the McBSP act as the master mode. The AM35x BSP does not currently support configuring the codec as the master.

Build options

No build options.

Driver API

The audio driver follows the "Wave API" used by Windows Embedded CE. More information regarding this API can be found at:

http://msdn.microsoft.com/en-us/library/ee485233.aspx

Example usage

To use the examples below, you need to copy the following files from the flat release directory of your OsDesign to your board using any mean (ActiveSync, USB drive, FTP, SDCard, …):

wavplay.exe
wavrec.exe
wavmixer.exe (make sure that AM35x_BSP\SRC\APP\WAVMIXER is included in the build)

The following commands need to be launched from a command line window or using a Telnet connection.

Play a sound file:

wavplay <.wav file name>

Record sound from the line input during 5 seconds:

wavrec -f <output file name> -t 5000

Display the available mixer controls:

wavmixer –l

Select Microphone as the recorder device and record for 3 seconds:

wavmixer –s IN 2 1

wavrec -f <output file name> -t 3000

Mute audio output:

wavmixer –s OUT 1 1

Unmute audio output:

wavmixer –s OUT 1 0

Enable Microphone +20 dB boost:

wavmixer –s IN 3 1

CAN Driver[edit]

Supported features

The BSP offers functionality for CAN communication using the J15 and J16 header pins located on the EVM application board. The CAN driver is based on the CPU’s High-End CAN controller (HECC).

It supports the following features:

Bus speed up to 1 Mbps
Programmable bit time according to CAN specification
Bus failure diagnostic
Automatic reply to a remote request message
Message filtering based on the Standard/Extended ID
Strobe pin feature to enable/disable the CAN transceiver

Registry entries

The registry configuration of the CAN driver is defined under:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\CAN\omap_can.reg

Key	Value	Description
Dll	omap_can.dll	DLL of the driver
Order	8	Global order in which drivers are loaded
Priority	0x80	Priority of the interrupt service thread
StrobePin	0x126	ID of the CAN Strobe pin
StrobePinPolarity	0	Active state of the CAN Strobe pin
BaudRate	0x3D090	Baud Rate of the CAN bus
CanCtrlIndex	0	Index of the CAN controller
maxRxMsg	256	Max number of messages stored in the receive queue
TxLowMaxElem	32	Size of the low priority Tx message queue
TxMediumMaxElem	32	Size of the medium priority Tx message queue
TxCriticalMaxElem	32	Size of the high priority Tx message queue

Limitations

No documented limitations.

Build options

No documented build options.

Driver API

The driver is implemented as a standard stream driver as described at:

http://msdn.microsoft.com/en-us/library/ee483176.aspx

It can be accessed using the IoControls detailed in the chart below:

IoControl	Description
IOCTL_CAN_COMMAND	Send Start/Stop/Reset commands to the driver
IOCTL_CAN_CONFIG	Configure the CAN driver
IOCTL_CAN_STATUS	Get information about the driver’s current status
IOCTL_CAN_SEND	Send one or more messages over the CAN bus
IOCTL_CAN_RECEIVE	Read one or more received messages
IOCTL_CAN_FILTER_CONFIG	Install/remove any class/subclass filter
IOCTL_CAN_REMOTE_CONFIGURE_AUTO_ANSWER	Set a message to automatically send on remote requests
IOCTL_CAN_REMOTE_REQUEST	Send a remote frame to another node on the bus

Example usage

Below is some sample code that configures the CAN driver and sends a message over the bus.

#include sdk_can.h

int _tmain(int argc, TCHAR *argv[], TCHAR *envp[])
{

IOCTL_CAN_COMMAND_IN cmdIn;
IOCTL_CAN_CONFIG_IN cfgIn;
IOCTL_CAN_SEND_IN sendIn;
CAN_MESSAGE msgArray[1];

// Open the CAN driver
HANDLE hCan = CreateFile(L"CAN1:",0,0,NULL,OPEN_EXISTING,0,NULL);
If (hCAN == NULL)
{
	goto error;
}

// Make sure the controller is stopped
cmdIn = STOP;
if(!DeviceIoControl(hCan,IOCTL_CAN_COMMAND,&cmdIn,sizeof(cmdIn),NULL,0,NULL,NULL))
{
 goto error;
}

// Reset the controller
cmdIn = RESET;
if(!DeviceIoControl(hCan,IOCTL_CAN_COMMAND,&cmdIn,sizeof(cmdIn),NULL,0,NULL,NULL))
{
 goto error;
}

// Configure the controller
cfgIn.cfgType = BAUDRATE_CFG;
cfgIn.BaudRate = 250000;
if(!DeviceIoControl(hCan,IOCTL_CAN_CONFIG,&cfgIn,sizeof(cfgIn),NULL,0,NULL,NULL))
{
 goto error;
}

// Start the controller
cmdIn = START;
if(!DeviceIoControl(hCan,IOCTL_CAN_COMMAND,&cmdIn,sizeof(cmdIn),NULL,0,NULL,NULL))
{
 goto error;
}
// Create a new message to send
msgArray[0].id.u32 =0;
msgArray[0].id.s_extended.id = 0x8721;
msgArray[0].id.s_extended.extended = 0x1;
msgArray[0].length = 1;
msgArray[0].MDH = 0xAA
msgArray[0].MDL = 0x55;
sendIn.priority = TXMEDIUM;
sendIn.timeout = 1000;
sendIn.nbMsg = 1;
sendIn.msgArray = msgArray;

// Send the message over the bus
if(!DeviceIoControl(hCan,IOCTL_CAN_SEND,&sendIn,sizeof(sendIn),NULL,0,NULL,NULL))
{
goto error;
}

// Stop the controller
cmdIn = STOP;
if(!DeviceIoControl(hCan,IOCTL_CAN_COMMAND,&cmdIn,sizeof(cmdIn),NULL,0,NULL,NULL))
{
 goto error;
}

error:

 if (hCan != NULL)
{
  // Close the CAN driver
	CloseHandle(hCan);
}
	return 0;
}

Keypad Driver[edit]

Supported features

The keypad driver provides a set of buttons mapped to virtual keys that are managed by GWES. The AM35x Application board exposes 10 push buttons that are mapped to configurable actions triggered when the buttons are pushed. GWES provides the ability for the applications to hook up events on a virtual key. Therefore virtual keys are an abstraction of the physical buttons for better portability of the applications.

Registry entries

The registry entries for the keypad driver are defined in:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\KEYPAD\keypad.reg

Key	Value	Description
Dll	keypad.dll	DLL of the driver
Order	0x10	Global order in which drivers are loaded
EnableWake	1	Register the keypad as a system wake up source

Limitations

As the keypad and the power key drivers share the same GPIO expander, those two drivers cannot be used simultaneously.

Build options

No documented build options.

Driver API

The keypad driver follows the standard Keyboard API that is used by GWES’ input manager. More information on Keyboard drivers can be found at:

http://msdn.microsoft.com/en-us/library/ee486116.aspx

By default, the keypad driver implements the following mapping:

Physical Button	Virtual Key
DOWN	VK_DOWN
UP	VK_UP
MENU	VK_MENU
MODE	VK_CONTROL
SHIFT	VK_LSHIFT
RWD	VK_LEFT
FWD	VK_RIGHT
STOP	VK_PERIOD
PLAY	VK_SPACE
REC	VK_TRECORD

This mapping can be modified from the file below:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\KEYPAD\vk_map.c

Example usage

The Windows Embedded CE Media Player takes advantage of the keypad driver using GWES framework. Refer to the ceplayer source code located under:

<WINCEROOT>\PUBLIC\DIRECTX\SDK\SAMPLES\WMP\CEPLAYER

Power Key Driver[edit]

Supported features

The power key driver allows the user to put the platform to suspend by pressing a button from the keypad during a minimum amount of time.

Registry entries

The keypad driver exposes its registry entries in the following file:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\PWRKEY\pwrkey.reg

Key	Value	Description
Dll	pwrkey.dll	DLL of the driver
Order	8	Global order in which drivers are loaded
priority	0x80	Defines the interrupt thread priority
pinId	0x108	Defines the power key GPIO (default is MENU button)
debouncePeriod	0x3E8	Defines for how long (in ms) the button has to be pressed

Limitations

As the keypad and the power key drivers share the same GPIO expander, those two drivers cannot be used simultaneously.

Build options

No documented build options.

Driver API

This power key driver does not expose any API. It is a standalone driver that is functional as soon as it is loaded at startup.

Example usage

Press the power button (default is "MENU") for more than one second and the platform will go to suspend mode.

NDIS EMAC Driver[edit]

Supported features

The EMAC driver is implemented following the NDIS specification detailed in the following article:

http://msdn.microsoft.com/en-us/library/ee486267.aspx

This driver exposes the onchip EMAC controller as a network interface that can be accessed from the applicative level through the Winsock API. The EMAC controller supports the following features:

Synchronous 10/100 Mbit operation
Dedicated CPPI DMA controller
Hardware error handling including CRC
RMII physical interface
MDIO module for PHY management
Configurable receive address matching/filtering
8K internal buffer descriptor memory

Registry entries

The NDIS configuration registry for the EMAC driver is found under:

<WINCEROOT>\PLATFORM\AM35x_BSP\SRC\DRIVERS\EMAC\omap_emac.reg

The following chart sums up the applicable registry configuration for the EMAC driver:

Key	Value	Description
DisplayName	EMAC Miniport Driver	Name of the NDIS network interface
Group	NDIS	Class of the network driver
ImagePath	omap_emac.dll	Name of the driver’s dll

Limitations

No documented limitations.

Build options

Variable	Description
SUPPORT_TWO_ETH_PORT	Enable support for dual PHY

Driver API

The EMAC NDIS driver is accessed at the applicative level using the Windows Sockets API described at:

http://msdn.microsoft.com/en-us/library/aa917471.aspx

Example usage

No example usage provided for this driver.

AM387xx EVM Specific Drivers[edit]

Audio Driver[edit]

Driver Features

The AM387x BSP contains an audio driver for the TLV320AIC3106 Audio Codec. The driver implements the WAVEDEV2 model. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee485632.aspx

The driver supports the following feature set:

Stereo playback to the HP OUT 3.5mm jack
Stereo record from the MIC IN 3.5mm jack
Input and output volume control
Sample rates supported: 8KHz, 16KHz, 11.025KHz, 22.05KHz, 44.1KHz, 48KHz, 96KHz
Mono and stereo streams supported
8 and 16-bit sample size supported
McASP used to communicate with AIC3106 (I2S format with DMA support)
McASP configured as clock master

Registry Entries

The audio driver registry entries are defined in:

<WINCEROOT>\PLATFORM\AM387x_BSP\SRC\DRIVERS\WAVEDEV2\am387x_wavedev2.reg

The registry entries are as follows.

Key	Value	Description
Dll	wavedev2drvr.dll	DLL into which the driver is built
Order	5	Global order in which drivers are loaded (0 earliest).
Priority256	0x46	IST priority
AudioCntrlRegAddr	0x48050000	Base address of the McASP used
IrqTx	0x54	McASP2 Tx interrupt number
IrqRx	0x55	McASP2 Rx interrupt number
EventIdTx	0x0C	EDMA event associated with McASP TX
EventIdRx	0x0D	EDMA event associated with McASP RX
EdmaEventQueue	0	EDMA event queue to use

Limitations

No documented limitations.

Build Options

There are no build options for this driver.

Driver API

The audio driver functionality is exposed via the standard CE waveform audio APIs.

There are some additional custom IOCTL’s implemented that support configuring the input gain. The IOCTL’s are defined in the following header:

<WINCEROOT>\PLATFORM\AM387x_BSP\SRC\INC\wavioctl.h

Example Usage

When the audio driver and Waveform Audio support are included in an OS design the following audio utilities are also built:

wavplay – Plays a WAV file
wavrec – Records a WAV file
wavevol – Adjusts the audio output volume. Command line parameter is the volume between 0 and 100.
wavtest – Provides input gain control.

The source code for wavevol and wavtest can be found in:

<WINCEROOT>\PLATFORM\AM387x_BSP\SRC\test\APPS

Three small audio test files are also included in the BSP. They can be found in

<WINCEROOT>\PLATFORM\AM387x_BSP\FILES

test.wav – Windows CE start-up sound
tones.wav – 10 tones at 80% amplitude
tones2.wav – 12 tones, an octave from middle C up, 50% amplitude

Display Driver[edit]

For AM387x, the display subsystem is not directly controlled by the ARM-A8. Instead there is a ARM Cortex M3 (referred to as VPSS M3) running HDVPSS firmware that controls almost all aspects of display. The display driver is responsible for downloading the HDVPSS M3 firmware using an interface module called Syslink on startup. The display driver is responsible for interfacing with DDRAW/GDI/GWES on WinCE side and the VPSS M3 firmware on the other side. It communications with VPSS M3 firmware using FVID2 interface over Syslink. Syslink and VPSS M3 are only released in binary form presently.

The WinCE display driver supports the GRPX0 pipeline of AM387x. Advanced features such as overlay support with GRPX1/GRPX2 pipelines as well as capture support are not implemented. Also software support is not implemented for vsync interrupt.

NDIS CPSW3G Driver[edit]

Supported features

The CPSW3G NDIS driver is implemented following the NDIS specification detailed in the following article:

http://msdn.microsoft.com/en-us/library/ee486267.aspx

This driver exposes the onchip CPSW3G switch as a network interface that can be accessed from the applicative level through the Winsock API.

The CPSW3G switch supports the following features:

Two Ethernet ports with Selectable G/MII, RMII, and RGMII interfaces
Synchronous 10/100/1000 Mbit operation
CPPI 3.1 compliant DMA controllers
Hardware error handling including CRC
MDIO module for PHY management
Address Lookup Engine
- 1024 total address lookup engine (ALE) entries of VLANs and/or MAC addresses
- VLAN support
- Receive or destination based Multicast and Broadcast limits
- MAC address blocking
- Source port locking
8k (2048 x 32) internal CPPI buffer descriptor memory
Full duplex mode supported in 10/100/1000 Mbps mode

Registry entries

The NDIS configuration registry for the CPSW3G driver is found under:

<WINCEROOT>\PLATFORM\AM387x_BSP\SRC\DRIVERS\EMAC\cpgmacMiniport.reg

The following chart sums up the applicable registry configuration for the CPSW3G driver:

Key	Value	Description
DisplayName	CPSW3G Miniport Driver	Name of the NDIS network interface
Group	NDIS	Class of the network driver
ImagePath	am387x_cpsw3g.dll	Name of the driver’s dll

Limitations

1) This version of BSP supports only single ethernet port mode. Two ports switch mode is not supported.

2) CPSW3G NDIS driver and KITL ethernet driver cannot coexist. If CPSW3G NDIS driver is enabled in Platform Builder Catalog, then KITL needs to be disabled and vice versa.

Build options

No documented Build options.

Driver API

The CPSW3G NDIS driver is accessed at the applicative level using the Windows Sockets API described at:

http://msdn.microsoft.com/en-us/library/aa917471.aspx

Example usage

No example usage provided for this driver.

AM335x EVM Specific Drivers[edit]

Audio Driver[edit]

Driver Features

The AM33x BSP contains an audio driver for the TLV320AIC3106 Audio Codec. The driver implements the WAVEDEV2 model. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee485632.aspx

The driver supports the following feature set:

Stereo playback to the HP OUT 3.5mm jack
Stereo record from the LINE IN 3.5mm jack
Input and output volume control
Sample rates supported: 8KHz, 16KHz, 11.025KHz, 22.05KHz, 44.1KHz, 48KHz, 96KHz
Mono and stereo streams supported
8 and 16-bit sample size supported
McASP used to communicate with AIC3106 (I2S format with DMA support)
McASP configured as clock master

Registry Entries

The audio driver registry entries are defined in:

<WINCEROOT>\PLATFORM\AM33x_BSP\SRC\DRIVERS\WAVEDEV2\am33x_wavedev2.reg

The registry entries are as follows.

Key	Value	Description
Dll	wavedev2drvr.dll	DLL into which the driver is built
Order	5	Global order in which drivers are loaded (0 earliest).
Priority256	0x46	IST priority
AudioCntrlRegAddr	0x4803C000	Base address of the McASP used
IrqTx	0x52	McASP1 Tx interrupt number
IrqRx	0x53	McASP1 Rx interrupt number
EventIdTx	0x0A	EDMA event associated with McASP TX
EventIdRx	0x0B	EDMA event associated with McASP RX
EdmaEventQueue	0	EDMA event queue to use

Limitations

No documented limitations.

Build Options

There are no build options for this driver.

Driver API

The audio driver functionality is exposed via the standard CE waveform audio APIs.

There are some additional custom IOCTL’s implemented that support configuring the input gain. The IOCTL’s are defined in the following header:

<WINCEROOT>\PLATFORM\AM33x_BSP\SRC\INC\wavioctl.h

Example Usage

When the audio driver and Waveform Audio support are included in an OS design the following audio utilities are also built:

wavplay – Plays a WAV file
wavrec – Records a WAV file
wavevol – Adjusts the audio output volume. Command line parameter is the volume between 0 and 100.
wavtest – Provides input gain control.

The source code for wavevol and wavtest can be found in:

<WINCEROOT>\PLATFORM\AM33x_BSP\SRC\test\APPS

Three small audio test files are also included in the BSP. They can be found in

<WINCEROOT>\PLATFORM\AM33x_BSP\FILES

test.wav – Windows CE start-up sound
tones.wav – 10 tones at 80% amplitude
tones2.wav – 12 tones, an octave from middle C up, 50% amplitude

Keypad Driver[edit]

Supported features

The keypad driver provides a set of buttons mapped to virtual keys that are managed by GWES. The AM335x GP board exposes 8 push buttons that are mapped to configurable actions triggered when the buttons are pushed. GWES provides the ability for the applications to hook up events on a virtual key. Therefore virtual keys are an abstraction of the physical buttons for better portability of the applications.

Registry entries

The registry entries for the keypad driver are defined in:

<WINCEROOT>\platform\AM33X_BSP\SRC\DRIVERS\KEYPAD\keypad.reg

Key	Value	Description
Prefix	KPD.dll	Prefix for device
Dll	keypad.dll	driver dll name
Index	1	Device Index
Order	0x10	Global order in which drivers are loaded

Limitations

There is no known limitaion

Build options

No documented build options.

Driver API

The keypad driver follows the standard Keyboard API that is used by GWES’ input manager. More information on Keyboard drivers can be found at:

http://msdn.microsoft.com/en-us/library/ee486116.aspx

By default, the keypad driver implements the following mapping:

Physical Button	Virtual Key
SW1	VK_DOWN
SW2	VK_UP
SW3	VK_LEFT
SW4	VK_RIGHT
SW5	1
SW6	2
SW9	3
SW10	VK_RETURN

This mapping can be modified from the file below:

<WINCEROOT>\PLATFORM\AM33X_BSP\SRC\DRIVERS\KEYPAD\vk_map.c

NDIS CPSW3G Driver[edit]

Supported features

The CPSW3G NDIS driver is implemented following the NDIS specification detailed in the following article:

http://msdn.microsoft.com/en-us/library/ee486267.aspx

This driver exposes the onchip CPSW3G switch as a network interface that can be accessed from the applicative level through the Winsock API.

The CPSW3G switch supports the following features:

Two 10/100/1000 Ethernet ports with GMII, RMII and RGMII interfaces
CPPI 3.1 compliant DMA controllers
Hardware error handling including CRC
MDIO module for PHY management
Address Lookup Engine
- 1024 addresses plus VLANs
- VLAN support
- Receive or destination based Multicast and Broadcast limits
- MAC address blocking
- Source port locking
8k (2048 x 32) internal CPPI buffer descriptor memory

Registry entries

The NDIS configuration registry for the CPSW3G driver is found under:

<WINCEROOT>\PLATFORM\AM387x_BSP\SRC\DRIVERS\EMAC\cpgmacMiniport.reg

The following chart sums up the applicable registry configuration for the CPSW3G driver:

Key	Value	Description
DisplayName	CPSW3G Miniport Driver	Name of the NDIS network interface
Group	NDIS	Class of the network driver
ImagePath	am33x_cpsw3g.dll	Name of the driver’s dll

Limitations

1) This version of BSP supports only single ethernet port mode. Two ports switch mode is not supported.

2) CPSW3G NDIS driver and KITL ethernet driver cannot coexist. If CPSW3G NDIS driver is enabled in Platform Builder Catalog, then KITL needs to be disabled and vice versa.

Build options

No documented Build options.

Driver API

The CPSW3G NDIS driver is accessed at the applicative level using the Windows Sockets API described at:

http://msdn.microsoft.com/en-us/library/aa917471.aspx

Example usage

No example usage provided for this driver.

PRU Driver[edit]

Supported features

The PRU subsystem includes the following main features:

Two PRUs each with:
- 8KB program memory
- 8KB data memory
12 KB general purpose shared memory
One Interrupt Controller (INTC)
16 software Events generation by 2 PRUs
One Ethernet MII_RT module with 2 MII ports and configurable connections to PRUs
One MDIO Port
One Industrial Ethernet Peripheral (IEP) to manage/generate Industrial Ethernet functions
One 16550-compatible UART with a dedicated 192 MHz clock
One Enhanced Capture Module (ECAP)

The PRU driver supports only the loading of firmware to the PRU subsystem.

Registry entries

The registry entries for the PRU driver are included in:

<WINCEROOT>\\PLATFORM\<BSP Folder>\SRC\DRIVERS\platform.reg

Key	Value	Description
Dll	prudrvr.dll	DLL of the driver
Order	0x30	Global order in which drivers are loaded
priority256	0x40	Priority of the Interrupt Service Thread

Limitations

This version of PRU driver only demonstrates the loading of firmware to the PRU subsystem.

Build options

No documented Build options.

Driver API

The PRU driver is implemented as a standard stream driver exposing the following IoControls:

IoControl	Description
PRUIOCTL_EXECUTE	Called when download and execute a firmware
PRUIOCTL_EXECUTE_CASE_NO	Called when download and execute a firmware test case
PRUIOCTL_SHOW_TEST_CASES	Shows firmware test cases available

Example usage

A PRU download test application (prutest.exe) and a sample firmware (PRU_memCopy.fw) are provided in this version of BSP to demonstrate the firmware download.

The sample firmware does a PRU internal memory to memory copy. The driver verifies the memory copy is successful and prints a message.

To execute the demonstration:

1) Enable OAL Retail Messages in Eboot prompt

2) Bootup the AM33x EVM

3) telnet to the AM33x EVM

4) At telnet prompt, type 'prutest' to see the options.

5) Type 'prutest -i ?' to see test cases

6) Type 'prutest -i n' to execute a test case and observe the output on terminal display.

BSP Installation[edit]

This section provides basic instructions for installation of the EVM BSP.

Install Required Software[edit]

Other software must be installed prior to installing this BSP. See section Required Software in this document for more information.

Installing the TI ARM_A8 BSP[edit]

In this release, following installers are provided for BSP:

1. Source for ARM-A8 processor

2. Demo Images for

i. OMAP35xx/OMAP37xx processor(For WEC7, OMAP35xx and OMAP37xx are separate installers)

ii. AM35xx processor

iii. AM335x processor

iv. AM387x processor

When installing the source package, the installer prompts if the user wants to install the BSP source under _WINCEROOT (C:\WINCE600 or C:\WINCE700). If the user selects this option (default: selected), then following folders are copied under _WINCEROOT:

PLATFORM\AM35x_BSP

PLATFORM\EVM_OMAP3530

PLATFORM\AM33X_BSP

PLATFORM\AM387X_BSP

PLATFORM\COMMON\SRC\SOC\COMMON_TI_V1

OS-Designs\EVM_3530

OS-Designs\AM35x_OSDesign

OS-Designs\AM335X_OS

OS-Designs\AM387X_OS

3rdParty\dvsdk_1_11_00_02

PUBLIC\PowerVR

IMPORTANT NOTE: Please make sure you back up the above folders and delete them from WINCEROOT folder before doing the installation of BSP, otherwise the compilation of BSP may fail

If you don’t select the above option, then you need to manually copy the BSP to _WINCEROOT before compiling the BSP. The folders mentioned below can be found under <BSP_INSTALL_PATH>\Sources

The EVM_OMAP3530 folder should be copied under <WINCEROOT>\PLATFORM.

The AM35x_BSP folder should be copied under <WINCEROOT>\PLATFORM.

The AM33x_BSP folder should be copied under <WINCEROOT>\PLATFORM.

The AM387x_BSP folder should be copied under <WINCEROOT>\PLATFORM.

The COMMON_TI_V1 folder should be copied under <WINCEROOT>\PLATFORM\COMMON\SRC\SOC.

If DVSDK is needed, then copy dvsdk_wince_01_11_00_02 under <WINCEROOT>\3rdParty.

If SGX drivers are needed, then copy PowerVR under <WINCEROOT>\Public.

If sample OS-Designs are needed, copy AM335X_OS, AM387X_OS, EVM_3530 and AM35x_OSDesign under <WINCEROOT>\OS-Designs.

PowerVR Catalog[edit]

If PowerVR folder is copied to ’<WINCEROOT>\PUBLIC\’, PowerVR Catalog items will be available in the ’Catalog Items View’ of Platform Builder in the ’Third Party’ section.

Note: See section in Quick Start Guide on Selecting the right version of PowerVR before building the OS-design.

DVSDK Catalog (OMAP35xx BSP only)[edit]

If dvsdk_1_11_00_02 (or later version of dvsdk) folder is copied to ’<WINCEROOT>\3rdParty\’, DVSDK Catalog items will be available in the ’Catalog Items View’ of the Platform Builder in the ’Third Party -> Texas Instruments -> Multimedia Framework’ section.

Building Images[edit]

This section provides a brief overview of the steps needed to use Platform Builder to create an OS Design for the EVM BSP. Working knowledge of the Windows CE development environment and procedures is assumed.

Create an OS Design Using Platform Builder[edit]

Using the Sample OS Design[edit]

The EVM BSP includes a sample OS Design. This may be used as a starting point for creating your OS Design. Follow these steps to use the sample OS Design.

Locate the sample OS Design in the OS Design directory of this release.

Copy the folder in the <WINCEROOT>\OSDesigns\ directory.

Depending on which BSP to use, open the corresponding OSdesign solution file for the BSP from <WINCEROOT>\OSDesigns\

Creating a New OS Design[edit]

The Platform Builder New Platform Wizard can be used to create an OS Design for use with the BSP.

Start Visual Studio.

Select New ->Project from the File menu.

Select the Platform Builder project type.

Select a desired name for the new project.

Select OK to launch the Windows Embedded CE OS Design Wizard.

Select EVM_OMAP3530 from the list of available BSPs.

Note that this BSP will only appear if it has been installed and the support for ARM was installed as a part of the Windows Embedded CE installation.

Continue the Platform Builder New Platform Wizard until complete.

For more information about using Platform Builder to create or modify an OS Design, consult the Platform Builder documentation.

Building the BSP[edit]

Procedure[edit]

Start Microsoft Visual Studio using the desired OS Design (the one that includes the BSP). Use the Build menu, Global Build Settings submenu and enable the following:

Copy Files to Release Directory After Build

Make Run-Time Image After build

Use the Project menu, <OS Configuration Name> Properties... command to examine the Build Options page:

If Enable Kernel Debugger or Enable KITL boxes are checked then the newly created OS image will only boot if the EVM is connected to Platform Builder using a KITL supported hardware connection.

Selecting/Deselecting "Write Run-time Image to Flash Memory" has no effect. To create NK.bin that can be flashed to NAND, please set the environment variable IMGNAND in your OS-design/Solution.

Use the Build menu, Build Solution command to build the BSP. This operation will do a complete build including sysgen of the OS components. This operation can also be performed using the context menu in the Solution Explorer.

Note: See section in Quick Start Guide on Selecting the right version of PowerVR before building the OS-design.

After the first successful complete build you can speed up your development cycle by limiting the build to only components that have changed. One way to do this is to navigate to your BSP in the Solution Explorer and do Targeted Builds using the context menu.

Note that any time the OS design has changed you will need to do a full rebuild that includes the sysgen step.

Checking For Excessive Image Size[edit]

The allowable size of the OS image depends on the configuration parameters in the file \FILES\config.bib. The final image must fit within the space allocated to the RAMIMAGE region. The space allocated to the RAM region can also be used if the AUTOSIZE option is enabled. If the size of the OS image exceeds the allowable size the image will not boot reliably.

Examine the output of the build log to for warnings that indicate that records were skipped when creating the .bin image. This indicates that the image did not fit in the space allocated. Unfortunately this does not generate a hard error and is easy to overlook.

A second restriction on the OS image is the size of the OS partition on the NAND flash chip. If you build an image that is targeted to flash it must be able to fit in the space allocated.

Note that this process applies to all image output files, including the XLDR and EBOOT. These bootloader components can’t make use of the AUTOSIZE option and therefore must be able to fit entirely within the space defined for the RAMIMAGE region in their respective .BIB files.

Output File[edit]

The BSP build process produces several output files including the OS image and several bootloader files.

NK.BIN[edit]

The operating system image is located in a single file called NK.BIN. NK.BIN is structured in a proprietary Microsoft file format containing data records. This file cannot be executed directly by the CPU nor can it generally be programmed directly into flash. However the bootloader is designed to understand this format and it parses the data and copies it to the correct destination in memory. NK.BIN is the file that Platform Builder will download to the bootloader running on the EVM.

The bootloader will copy the OS image to its destination in RAM and then jump to the image entry point. At that point control has passed from the bootloader to the initialization routines in the operating system image.

The build process will optionally create a second operating system image file called NK.NB0. This file will only be created if the correct options are defined in the config.bib configuration file. NK.NB0 is an exact copy of the operating system image as it should exist in memory. The NK.NB0 file is normally used with JTAG equipment or other tools that directly access Flash or RAM.

For more detail descriptions on the Windows CE system images refers to official Microsoft Windows CE documentations.

XLDRNAND.BIN[edit]

The initial bootstrap loader is located in a single file called XLDRNAND.BIN. This file also uses the proprietary Microsoft .BIN file format. The bootloader understands this file format, and also understands the unique XLDR storage requirements in NAND Flash.

Platform Builder can optionally be configured to download XLDRNAND.BIN to the EVM. When the bootloader detects this file it properly programs it to the first four good blocks of NAND Flash.

The build process also creates the XLDRNAND.NB0 file. This file is the exact representation of the XLDR as it must appear in memory. The build process uses this file as part of the process of creating a RAW image file that can be used by the pserial.exe to program the entire bootloader.

XLDRUART.nb0[edit]

The initial bootstrap loader for UART is located in a single file called XLDRUART.nb0. This file also uses the proprietary Microsoft .nb0 file format.

XLDRUART.nb0 is used by pserial utility to initially flash the board in preparation for flashing NAND over serial.

MLO[edit]

The initial bootstrap loader is located in a single file called XLDRSD.nb0. The build process creates the MLO file from the XLDRSD.nb0. This file is the SD boot version of xldr.

EBOOTNAND.BIN[edit]

The primary bootloader is located in a single file called EBOOTNAND.BIN. This file also uses the proprietary Microsoft .BIN file format.

Platform Builder can optionally be configured to download EBOOTNAND.BIN to the EVM. When the bootloader detects this file it properly programs it to after the XLDR region in the reserved portion of NAND Flash.

The build process also creates the EBOOTNAND.NB0 file. This file is the exact representation of EBOOT as it must appear in memory. The build process uses this file as part of the process of creating a RAW image file that can be used by the pserialtool to program the entire bootloader region outside of bootloader control.

EBOOTSD.nb0[edit]

The build process also creates the EBOOTSD.NB0 file. This file is the exact representation of EBOOT as it must appear in memory. This file is used with MLO when booting from SD Card.

RAW file[edit]

OMAP35x-NAND.RAW[edit]

The XLDR and EBOOT are combined into a single file in a format that is suitable for programming directly into NAND flash memory. This .RAW file can be used with the pserial tool to program a functional bootloader into flash memory.

AM35x-NAND.RAW[edit]

The XLDR and EBOOT are combined into a single file in a format that is suitable for programming directly into NAND flash memory. This .RAW file can be used with the pserial tool to program a functional bootloader into flash memory.

AM33x-NAND.RAW[edit]

The XLDR and EBOOT are combined into a single file in a format that is suitable for programming directly into NAND flash memory. This .RAW file can be used with MLO.uart to program a functional bootloader into flash memory.

AM387x-NAND.RAW[edit]

The XLDR and EBOOT are combined into a single file in a format that is suitable for programming directly into NAND flash memory. This .RAW file can be used with XLDRUART.nb0 to program a functional bootloader into flash memory.

Locating the Image Files[edit]

After a successful build, the image output files will be located in the flat release directory. This directory is typically a subdirectory of the OS design directory in the top level OSDESIGNS folder. The build process copies all the files that will eventually make up the final image output files to this directory. It then uses this directory as a staging area to create the final bootloader and OS images.

The Platform Builder Build menu, Open Build Window command can be used to open a command window with the current directory set to the flat release directory.

Booting the EVM[edit]

There are a number of sources that the EVM can be set to automatically boot from. This chapter describes those sources.

Boot switch Settings[edit]

OMAP35xx EVM[edit]

SW4 on OMAP35xx EVM is used to select different boot mode.

Booting from SD card Setting

SW4 Switch Position
1	2	3	4	5	6	7	8
ON	ON	ON	OFF	OFF	ON	OFF	OFF

Booting from NAND Setting

SW4 Switch Position
1	2	3	4	5	6	7	8
OFF	ON	OFF	ON	OFF	OFF	OFF	OFF

AM35xx EVM[edit]

SW7 on AM35xx EVM is used to select different boot mode.

Booting from SD card Setting

SW7 Switch Position
1	2	3	4	5	6	7	8
ON	OFF	OFF	ON	OFF	OFF	OFF	OFF

Booting from NAND card Setting

SW7 Switch Position
1	2	3	4	5	6	7	8
OFF	OFF	OFF	OFF	OFF	OFF	OFF	OFF

AM387x EVM[edit]

S1 and SW13 on AM387x EVM are used to select different boot mode. All pins on SW13 are set to OFF mode.

Booting from SD card Setting

S1 Switch Position
1	2	3	4	5	6	7	8	9	10	11	12
ON	ON	ON	OFF	ON	OFF	OFF	OFF	OFF	OFF	OFF	OFF

Booting from NAND Setting

S1 Switch Position
1	2	3	4	5	6	7	8	9	10	11	12
ON	ON	OFF	OFF	ON	OFF	OFF	OFF	OFF	OFF	OFF	OFF

AM335x EVM[edit]

SW3 and SW4 on AM335x EVM base board are used to select different boot mode. SW3 and SW4 settings are as follows:

SW4 Switch Position
1	2	3	4	5	6	7	8
ON	ON	ON	ON	ON	ON	OFF	ON

Booting from SD card Setting

SW3 Switch Position
1	2	3	4	5	6	7	8
OFF	ON	ON	ON	ON	ON	ON	ON

Booting from NAND Setting

SW3 Switch Position
1	2	3	4	5	6	7	8
ON	OFF	ON	ON	ON	ON	ON	ON

Booting from SD Memory Card[edit]

The EVM is capable of booting the BSP from a correctly formatted, programmed and inserted SD memory card. Use the TI SDCard boot utility provided in this release to do so. Select MLO and then EBOOTSD.nb0 to obtain a bootable SD Card.

Use the switch settings mentioned in Boot Switch settings to boot from SD Card.

Booting from NAND Flash[edit]

Flashing the board (OMAP35x or AM35x) over UART[edit]

Here are the steps needed in order to flash XLDR and EBOOT to NAND flash through serial communication.

Host Side Software utility

1) On the host side, a PC utility called pserial.exe is required to perform the first steps of this tutorial. If this utility is not present on the host computer, you might want to follow step 2 to 9.

2) Download host PC utility http://omap-u-boot-utils.googlecode.com/files/omap-u-boot-utils-pack-r0.2.tgz

3) pserial.exe is available in the bin directory of the downloaded tarball for WINXP x86 32 bits. If you need to compile and build your own pserial.exe utility, please follow steps 4 to 9.

4) Unzip the omap-u-boot-utils.tag-v0.2.0.tgz included inside the downloaded tarball to the location of your choice.

5) You should now have directory called nmenon-omap-u-boot-utils-1a51d6b5c5947ad94c58c266c4e735fd776d30d8’.

6) Follow instructions in the Windows section in omap-u-boot-utils\README to install MinGW gnu compiler and GnuWin32 applications.

7) Follow instructions in the Windows section in omap-u-boot-utils\README to set up your PATH environment variable. You may need to re-login for changes to take effect.

8) Start a cmd window and cd to youromap-u-boot-utils directorythen type make

9) This should generate pserial.exe.

Target Side Software

1) Build your OS Design in Release configuration.

2) Copy XLDRUART.nb0 and <BSP specific>-nand.raw from your Flat Release Directory to your folder containing pserial.exe.

Flashing NAND

1) If it is OMAP35x EVM, set boot switch to boot from NAND.

If it is AM35x EVM, set boot switch to boot from SD card.

2) Connect a serial cable between the device UART port (UART3 on OMAP35xx EVM and UART on AM35x EVM) and your PC’s COM1.

3) On PC, start a cmd window cd to yourpserial.exe directory then run pserial.exe –p COM1 –f XLDRUART.nb0

4) Power up the board. The download is in progress in the cmd window.

5) When the download is done ("file download completed" is shown), keep the board powered.

6) Bring up HyperTerminal: Start > All Programs > Accessories > Communications > HyperTerminal.

7) Configure COM1 to 115200:8:None:1:None

8) You should now see § every 10 seconds on HyperTerminal.

9) On HyperTerminal, choose Transfer > Send File…

10) Choose Xmodem from drop down menu on Dialog box.

11) Browse to yourOMAP35xx-nand.raw orAM35x-nand.raw fileand click Send.

12) Send progress is shown within 10 sec. This download takes about 3 minutes.

13) Once download is completed, turn off the board and change SW4 as follows to select NAND Flash as the boot device.

14) Power up the board. The board should now boot from NAND flash.

Flashing the board (AM387x) over UART[edit]

Steps to flash XLDR and EBOOT to NAND flash through serial communication:

Host Side Software utility

1) HyperTerminal is needed on the host side PC.

Target Side Software

1) Build your OS Design in Release configuration.

2) XLDRUART.nb0 and AM387X-nand.raw are generated in Flat Release Directory.

Flashing NAND

1) Set boot switch to boot from UART (BTMODE[4:0] = 10111).

2) Connect a serial cable between the device UART port and your PC’s COM1.

3) On PC, start HyperTerminal and configure it to 115200-8-EVEN-1

4) On HyperTerminal: Transfer > Send File > select ‘Xmodem’ on drop down and browse to xldruart.nb0 located in Flat Release Directory.

5) Remove any SD card from the EVM if there is any and boot up EVM.

6) Before 8 C's are displayed on HyperTerminal, click ‘Send’ and download should begin.

7) After xldruart.nb0 is downloaded, with EVM still running, change HyperTerminal setting to 115200-8-NONE-1

8) ‘§’s should now be displayed on HyperTerminal every 10 sec.

9) On HyperTerminal: Transfer > Send File > ‘Xmodem’ on drop down and browse to AM387X-nand.raw in the Flat Release Directory.

10) Click 'Send' and download should now begin.

11) When download is done, power off EVM

12) Change boot switch setting to boot from NAND flash (BTMODE[4:0] = 10011)

13) Power up the board. The board should now boot from NAND flash.

Flashing the board (AM335x) over UART[edit]

On AM335X, since the bootloader downloaded by ROM bootloader over UART will be put in a non-4K boundary location, which is in conflict to the EC7 requirement of bootloader's starting address must be at a 4K-boundary location, flashing AM335x board over UART can only be done by using a special MLO (MLO.uart) copied to SD card.

Steps to flash XLDR and EBOOT to NAND flash through serial communication:

Host Side Software utility

1) HyperTerminal is needed on the host side PC.

Target Side Software

1) Build your OS Design in Release configuration.

2) MLO.uart and AM33X-nand.raw are generated in Flat Release Directory.

Flashing NAND

1) Copy MLO.uart to SD and rename it to MLO

2) Set Boot pin to boot from SD: SW3[8:1]=00000001 SW4[8:1]=01000000

  (NOTE: label on sw is in reverse (as of 4Jan2012), “ON” is actually 0)

3) On PC, open HyperTerminal with 115200-8-NONE-1

4) Boot up EVM.

5) ‘§’s should now be displayed on HyperTerminal every 10 sec.

6) On HyperTerminal: Transfer > Send File > ‘Xmodem’ on drop down and browse to AM33X-nand.raw in Flat Release Directory.

7) Click 'Send' and download should now begin.

8) When download is done, power off EVM

9) Change boot switch setting to boot from NAND flash (SW3[8:1]=00000010 SW4[8:1]=01000000)

10) Power up the board. The board should now boot from NAND flash.

Flashing the board over Platform builder[edit]

If no bootloader is present in the NAND Flash already, follow the instructions to boot from SD Card, but instead of selecting the EBOOTSD.nb0, select EBOOTNAND.nb0 as only EBOOTNAND.nb0 provides NAND flash functionality in the bootloader. Once the SD Card is properly formatted, rename EBOOTNAND.nb0 on your SD Card to EBOOTSD.nb0 so that XLDR can find it during boot time.

After booting the device, download any image (XLDRNAND.bin, EBOOTNAND.bin or NK.bin) to the device to flash it automatically. Make sure to have the IMGNAND environment variable set when building NK.bin if you wish to flash it.

Eboot has an option to flash NK.bin automatically after downloading from SD card or from Platform builder. To enable this option, select the following option from Eboot menu:

[Flash Management] -> Enable flashing NK.bin

Flashing the board through SD card[edit]

To flash XLDR/Eboot/nk.bin from SD card,

1. Copy EBOOTND.bin/XLDRNAND.bin/NK.bin to SD card.

2. Enable flashing by select following option from Eboot menu:

     [Flash Management] -> [8]Enable flashing NK.bin

On OMAP35x and AM35x platforms, when flashing XLDR, it is imperative that you select ONLY hamming 1 bit ECC mode since this is the ONLY mode supported by ROM code. This can be done by selecting the following option:

   [Flash Management] -> [9]Set ECC mode -> 0 (hamming 1 bit ECC)

On AM387x and AM335x platforms, when flashing XLDR, it is imperative that you select ONLY BCH 8bit ELM-X ECC mode since this is the ONLY mode supported by ROM code. This can be done by selecting the following option:

   [Flash Management] -> [9]Set ECC mode -> 4(BCH 8bit ELM-X)

3. Change the SDcard settings for image name to ebootnd.bin/xldrnand.bin/nk.bin from following Eboot Menu:

    [SDCard Settings] -> [Enter Filename]

4. Select boot from SD card:

    [Select Boot Device] -> [NK from SDCard File]

If NK.bin is loaded, after flashing, the program will continue to boot Kernel. If XLDR/EBoot is loaded, reboot is needed.

Please note that since OMAP35x and AM35x BootROM can only recognize Hamming 1 bit ECC, XLDR should always be flashed in 1 bit ECC mode. Eboot should be flashed in desired ECC mode. When using BCH 4 bit and BCH 8 bit XLDR/EBOOT, please use the following Eboot menu to set to Hamming 1 bit ECC mode:

    [Flash Management] -> [9]Set ECC mode -> 0 (hamming 1 bit ECC)

Please note that since AM387x and AM335x BootROM can only recognize BCH 8bit ELM-X ECC, XLDR should always be flashed in BCH 8bit ELM-X ECC mode. Eboot should be flashed in BCH 8bit ELM ECC mode. Please use the following Eboot menu to set to BCH 8bit ELM-X or BCH 8bit ELM ECC mode:

    [Flash Management] -> [9]Set ECC mode -> 4(BCH 8bit ELM-X)

    [Flash Management] -> [9]Set ECC mode -> 3(BCH 8bit ELM)

When switch from betweem ECC modes, it is recommended to erase NAND before the operation.

Booting from NAND[edit]

Once the NAND is flashed correctly, change boot switch to select NAND Flash as the boot device and boot the board.

Switching to XLDR/EBOOT with a different NAND ECC (OMAP3530 and AM35X only)[edit]

Before switch to a XLDR/EBOOT binary with a different NAND ECC (Hamming 1 bit/BCH 4 bit/ BCH 8 bit), erase block range 0-15 from the following Eboot menu:

[Flash Management] -> Erase block range

Loading OS Images[edit]

The bootloader included in the BSP is capable of downloading and using new bootloader and OS images. This section describes the most commonly used image download methods. A working knowledge of the Windows CE development environment and procedures is assumed.

The bootloader is able to communicate with Platform Builder to download updated images. This includes the operating system image as well as updated versions of the XLDR and EBOOT.

The bootloader can program XLDR and EBOOT images into their correct location in the reserved portion of NAND flash. It automatically programs the OS image into the OS partition or downloads it directly to RAM depending on how the image was built.

EVM Setup[edit]

The bootloader must be configured to load an image from the Ethernet or USB RNDIS. Ethernet is the default setting if the configuration parameters have not been changed.

Download Images using Ethernet[edit]

OMAP35x EVM

Select option [2] on the serial boot menu to configure the boot device.
Select option [1] LAN9115 MAC.
Optionally save the settings.
Connect the EVM3530 Ethernet to the same subnet as the Host PC.

AM35x EVM

Select option [2] on the serial boot menu to configure the boot device.
Select option [1] for Internal EMAC or option [2] for LAN9311 MAC.
Optionally save the settings.
Connect the internal EMAC or LAN9311 Ethernet to the same subnet as the Host PC.

AM335x EVM

Select option [2] on the serial boot menu to configure the boot device.
Select option [1] for Internal EMAC.
Optionally save the settings.
Connect the internal EMAC to the same subnet as the Host PC.

AM387x EVM

Select option [2] on the serial boot menu to configure the boot device.
Select option [1] for Internal EMAC.
Optionally save the settings.
Connect the internal EMAC to the same subnet as the Host PC.

Download Images using USB RNDIS[edit]

This feature is only available for OMAP35x and AM35x BSPs. USB RNDIS connection requires installation of drivers on the Host PC and Host PC setup which is documented in the following article: http://msdn.microsoft.com/en-us/library/bb500929.aspx. Users must also assign a static IP address to the (RNDIS) network adaptor used to communicate with the EVM, or provide bridging between the RNDIS adaptor and the Host PCs main intranet adaptor; static IP address assignment will result in a faster boot.

Select option [2] on serial boot menu to configure the boot device.
Select option [2] USB RNDIS Fn.
Save the settings.
Connect the EVM USB OTG port to the Host PC USB Host port.

Setup Platform Builder[edit]

Platform Builder must be configured to download the OS image or bootloader file.

Start Visual Studio and select the Platform Builder project containing the EVM BSP.
Select the desired configuration (Release/Debug).
Select Properties from the Project menu to bring up the project properties dialog box.
Expand the Configuration tree and select the General node.
Select the desired .BIN file from the drop down dialog box. The available options will be the .BIN files that exist in the flat release directory corresponding to the OS design.

The default setting will be NK.BIN, allowing the OS image to be downloaded and optionally debugged. However, this mechanism allows the XLDR or EBOOT images to also be downloaded if necessary.

Configure Platform Builder Connectivity Options[edit]

Platform Builder must be configured to communicate with the EVM over the Ethernet connection (if using either Ethernet or USB RNDIS Fn). Platform Builder can communicate with any device on the same subnet as long as that device uses the EBOOT protocol.

1) Enter the Target menu, Connectivity Options , Target Device Connectivity Options.

2) Select Kernel Service Map to bring up the kernel services settings.

3) Set Target Device to CE Device.

4) Set Download to Ethernet.

5) Set Transport to Ethernet. This setting will be used whenever a KITL enabled image is run on the EVM.

6) Set Debugger to KdStub. This setting will be enabled the kernel debugger component when the debugger is included in the image running on the EVM.

7) Click the Settings button next to the Download box to bring up the Ethernet Download Settings dialog box.

8) Start the download operation on the EVM by selecting Option [0] (Exit and Continue). The EVM will obtain an IP address via DHCP if necessary, then start broadcasting BOOTME packets to the network.

9) Select the ID string corresponding to the EVM that will appear in the Ethernet Download Settings dialog box. It will be of the form EVM3530-xxxxx, where the last 5 digits are derived from the MAC address. Close the dialog box.

Note that the name under both the Download and Transport drop down boxes contain the same name that was just selected. Platform Builder will attempt to communicate with the IP address associated with this name on all subsequent connection attempts. Close the Connectivity Options dialog.

Download Image[edit]

Once Platform Builder has been configured to communicate with the EVM the image can be downloaded. The download operation is triggered from the EVM by broadcasting the BOOTME packet. Platform Builder listens for these packets and responds when it detects the request.

1) Ensure the EVM is still broadcasting BOOTME packets. Once an IP address has been obtained, it will broadcast the packets for approximately two minutes. The device will need to be reset and the download operation reinitiated if this time period has been exceeded.

Select Attach Device from the Target menu. The Download dialog box will appear, and the download will proceed as soon as a BOOTME packet is detected.

Load OS image through SD card[edit]

When booting system from SD card, NK.bin can also be loaded from SD card.

From Eboot main menu, select option [2] – Select Boot Device.

Then configure the boot device to be "NK from SDCard FILE".

Debugging[edit]

This section discusses the options available to debug EVM bootloader and OS images. A working knowledge of the Windows CE development environment and procedures is assumed.

Debugging the Bootloader[edit]

The bootloader does not contain a software debugger component that allows it to communicate with the kernel debugger in Platform Builder. As a result it is not possible to use breakpoints, step through code etc. The only supported debug method is the serial debug port.

Platform Builder provides a debugger plug-in interface called ExDI2 that allows JTAG vendors to leverage the kernel debugger features. A third party tool that supports the OMAP35xx or AM35xx processor family and the ExDI2 interface would provide the option to do bootloader source level debugging using the JTAG interface.

Debugging the Operating System[edit]

Platform Builder supports source level debugging with a debugger component in the kernel. The debugger must be included in the operating system image and the image must be configured to support a KITL connection to make use of this feature.

An OS design typically has two configurations that are created by default when the project is created. The Debug configuration disables compiler optimizations for ease of debugging, and includes the kernel debugger and KITL components. A Release configuration enables compiler optimizations and generally does not contain the kernel debugger. These options can be changed in the Configuration Manager.

It is possible to include the kernel debugger and KITL in both Release and Debug configurations. These two items are kernel DLLs that are included when the image is built and have no dependencies on the Release and Debug configurations. It is sometimes useful to include the debugger and KITL in a Release configuration along with debug versions of selected modules to enable a debugging environment that is closer to a normal production environment.

Image Configuration[edit]

The Kernel Independent Transport Layer driver is added to the OS image by clearing the IMGNOKITL environment variable. This is usually done in the Build Options node in the project Properties dialog. Select the desired configuration (Release or Debug) and ensure that the Enable KITL check box is set appropriately.

The kernel debugger is included in the image in a similar fashion. This component is controlled with the IMGNODEBUGGER environment variable. This variable is exposed in the Properties dialog with a check box as well.

It is important to note that an image with KITL included and enabled requires a connection to Platform Builder in order for it to boot. The operating system will hang waiting for the connection to complete if the KITL link is active. Do not include KITL in an image unless a connection to Platform Builder is available or KITL is disabled via the serial bootloader menu.

Ethernet KITL[edit]

The Ethernet port is normally used as the KITL transport as it provides the fastest speeds. The Ethernet port must be connected to a hub that is on the same subnet as the Host PC running Platform Builder. The Ethernet port must be selected as the Debug device using the serial bootloader menu.

The Ethernet KITL transport uses a dedicated set of routines to communicate with the kernel. It does not use the Ethernet NDIS miniport driver. It is critical that the Ethernet miniport driver be disabled when Ethernet KITL is in use. Failure to do so will cause the device to hang because the Ethernet driver will interfere with the KITL communications. The Ethernet NDIS miniport driver can be disabled by setting the BSP_NOETHERNET environment variable. The VMINI component can be used to expose the Ethernet KITL link to applications.

USB RNDIS KITL[edit]

The USB OTG port can also be used as the KITL transport. This port is normally used when an Ethernet port is not available. It is more difficult to set up because it requires a USB driver to be installed on the Host PC and it requires either a network bridge or Internet Connection Sharing to be enabled. USB RNDIS KITL is typically not as stable as Ethernet KITL because of the increased complexity of the interface.

The USB RNDIS KITL transport uses a dedicated set of routines to communicate with the kernel. It does not use the standard USB function or OTG stacks. It is critical that all USB drivers be disabled when USB RNDIS KITL is in use. The USB RNDIS KITL implementation automatically disables the standard USB drivers when KITL is active.

Serial Debug Messages[edit]

The serial debug port at CPU UART3 is exposed on the RS-232 connector labeled UART3 on the main board. This port will print out all debug messages until the KITL transport is loaded. After KITL is initialized only low level messages that bypass the KITL interface will be written to this port.

The debug port can be disabled and made available for normal application use if desired. It is important to note that the UART3 serial driver should not be loaded if this port is to be used as a debug port. The UART3 serial driver can be disabled by setting the environment variable BSP_NOCOM3.

It is sometimes beneficial to use serial debug messages instead of the KITL link. This option can print debug messages to the serial port much faster than they will appear over an Ethernet/USB RNIDS KITL link because of the overhead of the KITL protocol and Platform Builder synchronization. To use this feature simply remove KITL and the kernel debugger from the OS image. All messages will then be monitored with a terminal program.

Note that these messages will not appear in the Platform Builder Debug window because Platform Builder only shows the messages that come over a KITL link.

Getting started[edit]

This chapter is a guide for working with the Texas Instruments EVM platform mentioned at the start of this document. Hardware setup is provided.

OMAP35xx EVM overview[edit]

Here is a picture of the top view of OMAP35xx EVM board.

AM35xx EVM overview[edit]

Here is a picture of the AM35xx EVM board along with a brief description of the different components which are part of the eXperimenter board (on the left) and the application board (on the right). Notice the screws in the middle which hold both boards together.

DVI Functionality Setup[edit]

Here are the steps needed in order to enable and use DVI.

1) On AM35xx EVM, before booting the board, make sure Switch 8 on S7 is set to "on".

2) For AM35xx, use the HDMI/DVI cable (HDMI end connected to EVM, DVI to monitor). For OMAP35xx, a DVI cable is required.

3) Boot the board.

4) In EBOOT’s configuration menu, go to "Select Display Resolution" and choose the resolution for the DVI output among those available.

5) Exit the menu and load the kernel.

Flashing the board[edit]

Refer section 5.1 on how to flash NAND over serial.

Video Input Functionality Setup[edit]

The video input driver supports composite, component and S-Video inputs (via TVP5146). A sample application to test video capture is also provided.

OMAP37xx/DM37xxx EVM setup

The video inputs on the OMAP35xx and DM37xx EVMs are ready to use out of the box. No additional hardware setup is required.

AM35xx EVM setup

Before booting the board, make sure "user switches" on the application board are configured as this: 1,2: ON ; 3,4: Don’t care.
In your OSDesign, make sure VRFB driver is not selected.
If using BSP 01.02.00 and later, use newer app board revisions (1017100 and later). See note on AM35x EVM here. If using older rev of BSP (01.01.00 or earlier), then older rev of app boards (1013690, 1014473) should work fine.

Sample Test Application

CaptureTest is a DirectShow utility that can be used to capture video from the EVM’s video inputs (S-Video, component and Composite) and optionally encoded into H.264 or MPEG4 format in an ASF container using TI’s DSP based encoders. CaptureTest also displays performance metrics such as fps and ARM/DSP utilization. The source code for CaptureTest can be found under %WINCEROOT%\PLATFORM\<BSP>\SRC\APP\CAPTURETEST.

Command Line Options

To view the command line options supported by CaptureTest, run it with the /? switch and you will see the following output:

Usage: CaptureTest [options]
Options:
        /auto                 - auto-run graph without user input. 
        /br {bitrate}         - Specify encode bitrate in bps
                                default: 2000000 bps
        /cap {wxh@fps}        - Specify capture params in the specified format           
                                e.g. 640x480@30,default: 720x480@30
        /file {filename}      - Specify output ASF file
                                If /file option is not specified, or 
                                /venc is none, NULL sink is used
        /sd                   - output file will be created on SD card
        /nand                 - output file will be created on NAND flash
        /usb                  - output file will be created on USB storage
        /pv                   - Enable preview (disabled by default)
        /time                 - time in ms to run graph and exit app
                               (ignored if /auto is not specified)
        /venc {encoder}       - h264, mpeg4, raw or none
                                default: None
        /vin {video input}    - svideo, ypbpr or av
                                default: Composite(AV)

Further explanation of some of the command line options:

/auto - Specifying this will cause CaptureTest to run in a non-interactive mode i.e. the capture graph will run automatically after the application is executed. When used with the /time option, it facilitates running the application in batch mode from a script. By default, when /auto is not specified, the application starts in interactive mode with the filter graph stopped. To run the graph, the user must key in ’r’ inside the application window. To stop the graph when running, the user must key in the ’s’ key. If /auto is specified but /time is not specified, the graph will run indefinitely until the user presses the ’s’ key or shuts down the application.

/time - It is used with /auto to specify the time duration for which the capture graph will run after which the application will shut down automatically. It is ignored if /auto is not specified.

/br - The bitrate of the encoder can be specified with this option. If /br is not specified, the encode bitrate defaults to 2Mbps.

E.g. specifying /br 1000 means the encoder will be configured to encode at a bitrate of 1Mbps

/cap - Some capture driver parameters such as capture resolution and frame rate can be changed with this option. Only parameters supported by the driver will be supported. When CaptureTest runs, it displays the capabilities advertised by the capture driver.

CaptureTest: Capabilities of capture driver --->
CaptureTest:0 - (Video, UYVY, 720x480, 16 bpp, 30 fps, 165.888 mbps)
CaptureTest:1 - (Video, UYVY, 704x480, 16 bpp, 30 fps, 162.201 mbps)
CaptureTest:2 - (Video, UYVY, 352x240, 16 bpp, 30 fps, 40.550 mbps)
CaptureTest:3 - (Video, UYVY, 176x120, 16 bpp, 30 fps, 10.137 mbps)
CaptureTest:4 - (Video, UYVY, 720x576, 16 bpp, 25 fps, 165.888 mbps)
CaptureTest:5 - (Video, UYVY, 704x576, 16 bpp, 25 fps, 162.201 mbps)
CaptureTest:6 - (Video, UYVY, 352x288, 16 bpp, 25 fps, 40.550 mbps)
CaptureTest:7 - (Video, UYVY, 176x144, 16 bpp, 25 fps, 10.137 mbps)
CaptureTest:8 - (Video, UYVY, 640x480, 16 bpp, 30 fps, 147.456 mbps)
CaptureTest:9 - (Video, UYVY, 320x240, 16 bpp, 30 fps, 36.864 mbps)
CaptureTest: Setting capture parameters to 720x480@30fps

By default, CaptureTest will try to set the capture parameters to 720x480 at 30fps. If this is not, supported by the capture driver, you will see an error message and the capture driver will default to capability 0 advertised by it. A current limitation of this option is that the YUV pixel format cannot be changed from the pixel format specified in capability 0. This will be fixed in a future release.

/vin - This option is used to specify the video capture input port on the EVM. The following values are supported:

svideo - S-Video port

ypbpr - Component video port

av - Composite video port

/venc - This option is used to specify if an encoder will or will not be used to encode the captured video. The following options are supported:

h264 - Use the TI H.264 encoder. Performance stats (fps, ARM & DSP utilization etc.) are printed if the "Perf" and "Stats" debug zones are enabled for TIMM.DLL and the "Stats" debug zone is enabled for H264VideoEncoder.dll.

mpeg4 - Use the TI MPEG4 encoder. Performance stats (fps, ARM & DSP utilization etc.) are printed if the "Perf" and "Stats" debug zones are enabled for TIMM.DLL and the "Stats" debug zone is enabled for MPEG4VideoEncoder.dll..

none - Don’t use an encoder (no performance stats are printed).

raw - CaptureTest uses a sample grabber filter to measure the time duration between consecutive frames. It prints performance stats (fps & ARM utilization) based on this if the "Perf" and "Stats" debug zones are enabled for CaptureTest.exe.

/file - This option is used to specify the name of a file where CaptureTest will write the encoded video in ASF container format. By default, the file will be created in the root directory \ unless an explicit path is specified.

E.g. \temp\clip.asf

A limitation of this option is that it will not parse path names with spaces even if quotes are used to encapsulate the name.

E.g. \"Storage Card"\clip.asf

To overcome this limitation, files can be stored on a SD card using the /sd switch to accompany /file. The switches /nand and /usb are also available if the output file is to be saved to NAND and USB storage respectively.

E.g. Specifying "/file clip.asf /sd" will save the encoded output to \Storage Card\clip.asf

If /file is not specified, encoded frames are sent to a Null Sink filter.

Limitations

Preview does not work when the BSP 1.x is built with VRFB enabled and if you dont have the CE6 Nov 2010 monthly update installed on your setup. The Nov 2010 CE6 monthly update fixes the stride issue and Preview will work with VRFB enabled after this update is applied.
Capturetest output is exclusively delivered as RETAILMSGs, so to view them, enable OAL retail messages in the bootloader or make sure KITL is enabled.
Captured YUV frames cannot be saved to a file with the /file option when /venc none or /venc raw is specified.
The YUV pixel format cannot be changed from the pixel format specified in capability 0. This will be fixed in a future release.
For BSP 2.x releases, the video encoder option is not suported.

RTC Demo[edit]

The wakeme application has been provided to test and demonstrate the RTC wakeup feature in the TI ARM_A8 BSP. Wakeme will suspend the platform for a default of 120 seconds and will then be resumed by the RTC. This timeout time is configurable in the command line execution of the application.

Location of Test[edit]

The wakeme rtc test can be found in the BSP test directory:

\PLATFORM\<BSP Folder>\SRC\test\wakeme

Using the Wakeme Application[edit]

The wakeme application can be executed in one of the following ways:

Using built-in command line or telnet:

i.e. – the following will suspend the platform for 3 minutes:

wakeme.exe 180

Running the executable without arguments uses the default 120 second RTC timeout.

Note that the timeout specified should be greater than (atleast twice) the min RTC resolution supported by the device (10 secs for OMAP35x and 60 secs for AM35x)

CAN Setup and Demo[edit]

Canbench[edit]

Canbench is an application that sends data. Someone must be listening on the BUS and acknowledge the message (Kvaser CAN probe is a good tool for this).

Board Setup

Probe.DB9.7 <-> J36.1

Probe.DB9.2 <-> J36.2

Probe.DB9.3 <-> J36.4

J15.3 <-> J36.2 (This is the 120 Ohm line adaptation resistor)

Running the Demo

This section needs to be filled out, specifically how to use the Kvser CAN probe applications

CanbenchRX[edit]

CanbenchRX is an application that receives data. Someone must be sending data on the BUS (Kvaser CAN probe is a good tool for this).

Board Setup

Probe.DB9.7 <-> J36.1

Probe.DB9.2 <-> J36.2

Probe.DB9.3 <-> J36.4

J15.3 <-> J36.2 (This is the 120 Ohm line adaptation resistor)

Running the Demo

This section needs to be filled out, specifically how to use the Kvser CAN probe applications

CanDemoMaster/CanDemoEcho[edit]

CanDemoMaster is a simple echo test app for CAN. The application sends data to the bus. It also receives packets from the BUS.

CanDemoEcho is a simple echo test application for CAN. The application loops waiting for CAN messages. When one or more messages are received, they are sent back to the BUS.

Board Setup

Two board setup required, connected as follow:

B1.J15.1 <-> B2.J15.1

B1.J15.2 <-> B2.J15.2

B1.J15.4 <-> B2.J15.4

B2.J15.3 <-> B2.J36.2 (This is the 120 Ohm line adaptation resistor)

To add a probe (Such as Kvaser USBCAN II) :

Probe.DB9.7 <-> B1.J36.1

Probe.DB9.2 <-> B1.J36.2

Probe.DB9.3 <-> B1.J36.4

The probe should be configured in "silent" mode if possible. Otherwise the probe will ack the CAN packets (and the tests will show less errors)

Running the Demo

Run test through command line or batch script.

Example: Echo TX messages have higher priority (lower ID) than master Tx. Fixed baudrate.

Run the following command on board 1:

candemoecho -d10000 -b500 -idtx120 -idrx121

Run the following command on board 2:

candemomaster -d8000 -gmax1 -b500 -idtx121 -idrx120

Sample Applications[edit]

This chapter mentions a few sample applications that are provided with the BSP.

Shell Commands[edit]

The Windows CE shell has been extended with custom OMAP shell commands. These commands can be accessed in multiple ways:

For KITL build, use Target control window in Platform builder. Type ? to list the commands.

Ex: rotate

This rotates the LCD screen by 90

For NON-KITL builds, but Telnet enabled: Telnet to the box and use "do ?" command to list the available commands. The commands are same as above except that "do" needs to be appended before the command

Ex: do rotate

For NON-KITL builds with telnet disabled, use the cmd window on EVM’s desktop to execute the same commands as in telnet window

Ex: do rotate

The commands that are available include dumping/modifying the registers, rotate LCD screen, turn display/TV out/DVI on and off, etc

Silverlight Demos[edit]

"Silverlight for Windows embedded" catalog entry is enabled by default in the OS designs provided by TI. Similarly hardware acceleration of Silverlight is enabled by default using the BSP_XRPLUGIN_OPENGL flag in the OSDesign environment variable. The BSP_XRPLUGIN_OPENGL flag results in the use of Microsoft's Silverlight OpenGL plugin. The Graphics acceleration for most cases will result in better rendering speed and lower CPU usages (since the work is deferred to the SGX).

If you have your own OSDesign then make sure that the "Silverlight for Windows Embedded" catalog under "Shell and User Interface" category is enabled and that the BSP_XRPLUGIN_OPENGL environment variable is set.

If you want to disable hardware acceleration of Silverlight, then BSP_XRPLUGIN_OPENGL should be undefined for the platform; in which case the system will use the GDI plugin (software) for Silverlight applications.

WinCE 6.0 BSP[edit]

The OSDesign provided by default for the different platforms contain some Silvelight applications which are incorporated in the final image and are embedded in the WinCE desktop. These applications are based on Microsoft’s provided sample code for Silverlight with some additions made to the functionality to support rotation of the display.

When executing any of these applications from the desktop (Bounce, Bubbles or Carousel) the system will attempt to show it in Landscape mode to use as much as possible the display size. When the application runs it will show the number of Frames Per Second (FPS) along the CPU usage for the given application.

WEC7 BSP[edit]

The silverlight demos (Bubbles, Bounce, Carousel) are not part of WEC7 release from Microsoft and hence not included in the WEC7 BSP release. But the files can be copied from the WinCE6 installation/WinCE6 BSP release and demos can be run using the following instructions.

KITL build:

Copy xamlperf.exe, bounce.xaml, bubbles.xaml, carousel.xaml from WinCE6 BSP release into FLATRELEASE folder.
Copy the .png files for each of the demos (from C:\WINCE600\PUBLIC\COMMON\OAK\FILES\XAMLPERF\BUBBLES, C:\WINCE600\PUBLIC\COMMON\OAK\FILES\XAMLPERF\BOUNCE, C:\WINCE600\PUBLIC\COMMON\OAK\FILES\XAMLPERF\CAROUSEL) into \Windows dir of the target.
Run the following commands for the demos.

  s xamlperf \Release\bounce.xaml
  s xamlperf \Release\bubbles.xaml
  s xamlperf \Release\carousel.xaml

Non-KITL build:

Assuming telnet is enabled.

Copy all the files mentioned above into \windows folder of the device (this can be done by having all the files mentioned on a SD card and then copying them to the \windows folder)
Then run the following commands from the telnet window(or from the cmd window on the device)

  xamlperf \Windows\bounce.xaml
  xamlperf \Windows\bubbles.xaml
  xamlperf \Windows\carousel.xaml

PowerVR Demos[edit]

Provided in the BSP release, a directory named PowerVR-Demos contains a set of applications that can be used to validate and test the proper behavior of the PowerVR installation in the system. To run these files, any of these mechanisms can be used:

For KITL enabled builds:

Ensure that the applications are copied into the Flat Release Directory. E.g. Copy the OGLESChameleonMan.exe into _WINCEROOT\OSDesigns\EVM_3530\EVM_3530\RelDir\EVM_OMAP3530_ARMV4I_Release or the appropriate directory.

Once the file is present in the flat release directory, either from Visual Studio, use the "Target" ? "Run Programs" menu to execute the desired application.

Or, use the Command Prompt (Alt+1) to execute the application from the command prompt (e.g. s OGLESMouse).

For NON_KITL builds

The applications need to be copied into the device. The easiest way to do this is to copy the application(s) into an SD card and use the "Start" ? "Run" menu to open the SD Storage contents and execute the desired application.

The demos provided are built to show the performance of that particular demo in terms of FPS, which will be displayed in form of Retail Messages (e.g. the WinCE Debug Log window in Visual Studio for KITL enabled images) and can be used for reference purposes. In these the eglSwapInterval has been set to zero, allowing the application to render freely without waiting for any event. The Chameleon Man application has been modified so the FPS display is presented directly on the display as well, therefore it can be read for images that don’t have any means to present Retail Messages.

The OGLESChameleonMan, OGLESMouse and OGLESVase are applications that use the OGLES1.1 standard while the OGLES2Skybox is based on the OGLES2 standard.

Silverlight based video player (WEC7 only)
[edit]

If silverlight and windows video player is enabled in the Catalog, then you will be able to play video files using the silverlight video player. Just double click on the video file and silverlight video player will launch and play the file. Note there are some limitation with this player when using TI DSP based codecs. See limitations section here.

Sample DShow Player Application (ceplayit) (WEC7 only)
[edit]

Since silverlight based video player have few limitations on our BSP 2.x releases, the sample Dshow player application ceplayit is recommended for video playback demo purposes. Find a detialed readme.txt at %_WINCEROOT%\public\directx\sdk\samples\dshow\Players\ceplayit. This player is included by default in the sample OS-design shipped with the BSP 2.x release. To include it in your OS-design, define an environment variable sysgen_dshow_sample in your OS-design and add the following line to your bib file.

ceplayit.exe $(_FLATRELEASEDIR)\ceplayit.exe NK

Example Usage:

ceplayit \storage_card\demo.avi

Support for BeagleBone[edit]

Release 2.30 contains preliminary support for AM335x based BeagleBone platform. This BSP has not gone through complete system test cycle and users of this BSP are expected to add features and harden the BSP as per their needs. Following features are available and have been tested:

Because of lack of LCD, windows desktop is seen on remote display
3D graphics support using PowerVR
Ethernet Connectivity
USB OTG Support (Port 0 - function only; Port 1 - host only)

Note: Real time performance of Video and Graphics demos is not good due to remote display. This is not a chip limitation since the same applications run fine on the AM335x EVM.

{{

switchcategory:MultiCore=

For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article WinCE-BSP ARM-A8 User Guide here.

Keystone=

For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article WinCE-BSP ARM-A8 User Guide here.

C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article WinCE-BSP ARM-A8 User Guide here.

}}

Links

Amplifiers & Linear
Audio
Broadband RF/IF & Digital Radio
Clocks & Timers
Data Converters

DLP & MEMS
High-Reliability
Interface
Logic
Power Management

Processors

Switches & Multiplexers
Temperature Sensors & Control ICs
Wireless Connectivity

WinCE-BSP ARM-A8 User Guide

Contents

Introduction[edit]

Requirements[edit]

Required Experience[edit]

Required Software[edit]

Required JTAG Tools[edit]

Required Network Capabilities[edit]

Notation Conventions[edit]

Related Documentation[edit]

BSP Features[edit]

Bootloader (EBOOT)[edit]

Bootloader and Initialization Sequence[edit]

Low Level Initialization[edit]

Device Configuration Parameters[edit]

Serial User Interface[edit]

NAND Flash Organization[edit]

Supported NAND chip[edit]

Reserved Area (Bootloader/Configuration Parameters)[edit]

NAND ECC support[edit]

OS Partition[edit]

File System Partition[edit]

OAL Features[edit]

Features[edit]

TI ARM_A8 Common Drivers[edit]

Display Driver[edit]

OMAP35x EVM Display Modes (for OMAP35xx/DM37xx)[edit]

AM35x eXperimenter board Display Modes[edit]

AM335x GP EVM Display modes[edit]

AM387x EVM Display modes[edit]

GPIO Driver[edit]

1-Wire/HDQ Driver[edit]

McASP Support Library (AM387xx and AM33x Only)[edit]

McBSP Driver (OMAP35x and AM35x Only)[edit]

SPI Driver[edit]

NAND Flash Driver[edit]

NDIS SMSC9118 Driver[edit]

Notification LED Driver[edit]

Power Management Driver[edit]

SDHC Driver[edit]

SDMA Driver[edit]

EDMA Driver[edit]

Touchscreen Driver[edit]

UART Driver[edit]

USB Host Driver[edit]

USB OTG Driver[edit]

A Note about USB Audio[edit]

Video input/Camera Driver[edit]

OMAP35xx EVM Specific Drivers[edit]

Audio Driver[edit]

Keypad Driver[edit]

Power Key Driver[edit]

AM35xx EVM Specific Drivers[edit]

Audio Driver[edit]

CAN Driver[edit]

Keypad Driver[edit]

Power Key Driver[edit]

NDIS EMAC Driver[edit]

AM387xx EVM Specific Drivers[edit]

Audio Driver[edit]

Display Driver[edit]

NDIS CPSW3G Driver[edit]

AM335x EVM Specific Drivers[edit]

Audio Driver[edit]

Keypad Driver[edit]

NDIS CPSW3G Driver[edit]

PRU Driver[edit]

BSP Installation[edit]

Install Required Software[edit]

Installing the TI ARM_A8 BSP[edit]

PowerVR Catalog[edit]

DVSDK Catalog (OMAP35xx BSP only)[edit]

Building Images[edit]

Create an OS Design Using Platform Builder[edit]

Using the Sample OS Design[edit]

Creating a New OS Design[edit]

Building the BSP[edit]

Procedure[edit]

Checking For Excessive Image Size[edit]

Output File[edit]

Silverlight based video player (WEC7 only)
[edit]

Sample DShow Player Application (ceplayit) (WEC7 only)
[edit]