2 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Copyrights
Copyrights
© Cypress Semiconductor Corporation, 2012-2013. The information contained herein is subject to change without notice.
Cypress Semiconductor Corporation assumes no responsib ility for the use of any circu itry other than circuitry embodied in a
Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted
nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an
express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components
in life-support systems, where a malfunction or failure may reasonab ly be expected to result in significant injury to the user.
The inclusion of Cypress products in life-support systems application implies that the manu facturer assumes all risk of such
use, and in doing so indemnifies Cypress against all charges.
Any Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress), and is protected
by, and subject to worldwide patent protection (United States and foreign), United States copyright laws, and international
treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-tran sferable license to copy, use, modify,
create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating
custom software and/or firmware in support of licensee product to be used only in conjunction with a Cypress integrated
circuit as specified in the appl icable agreemen t. Any reproduction, mod ification, transl ation, compilatio n, or representation of
this Source Code except as spe c ified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials
described herein. Cypress does not assume any liability arising out of the application, or use of any product or circuit
described herein. Cypress does not authorize its products for use as critical components in life-support systems, where a
malfunction or failure may reasonably be expected to result in sign ificant inj ury to th e user. The inclusion of Cypress’ product
in a life-support systems application implies that the manufacturer assumes all risk of such use, and in doing so indemnifies
Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
WirelessUSB™, enCoRe™, and PSoC Designer™ are trademarks and PSoC® is a registered trademark of Cypress
Semiconductor Corp. All other trademarks or registered trademarks referenced herein are property of the respective
corporations.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 3
Contents
1. Introduction 5
1.1 Kit Contents.............. ... ................ .... ... ... ... ................ .... ... ... ... ................ .... ... ... ... .........5
1.2 PSoC Designer™ 5.3 ..................................................................................................5
1.3 Additional Learning Resources.............. ... .... ... ... ... ... .... ... ................ ... ... .... ... ... ... .... ... ..5
1.4 Documentation Conventions........................................................................................6
1.5 Document Revision History ........................................................................................6
2. Getting Started 7
2.1 Install Software ............................................................................................................7
3. Kit Operation 9
3.1 Install Hardware...........................................................................................................9
3.1.1 Default Jumper Settings...................................................................................9
3.2 Programming and Emulation Procedures..................................................................10
3.2.1 Programming Steps........................................................................................10
3.2.2 Emulation Steps.............................................................................................12
4. Hardware 13
4.1 System Block Diagram ................ .... ... ... ... .... ... ... ... ... .... ... ................ ... ... .... ... ... ... .... ...13
4.2 Functional Description ........ ... ... ... .... ... ... ... ................ .... ... ... ... .... ... ... ... ... .... ................14
4.2.1 Voltage Regulator....... ... ................ .... ... ... ... ... .... ................ ... ... ... .... ... ... ..........15
4.2.2 MCU Power Selection................ ... .... ... ... ... ... ................. ... ... ... ... .... ... ... ... .... ...16
4.2.3 WirelessUSB-NL Radio Header.................... .... ... ... ... .... ... ... ... ... .... ... ... ... .... ...17
4.2.4 USB Mini-B Connecter............................ ... ... .... ... ... ... ................ .... ... ... ... .... ...17
4.2.5 ICE Header ....................................................................................................18
4.2.6 enCoRe II/enCoRe V Programming Selector.................................................19
4.2.7 MCU Header.................... .... ... ................ ... ... .... ... ... ... ................ .... ... ... ... .... ...20
4.2.8 MCU Reset Button.................. ... ... .... ... ... ................ ... .... ... ... ... ................ .... ...21
4.2.9 Logic Analyzer Header...................................................................................22
4.2.10 ISSP Header..................................................................................................22
4.2.11 I2C Header.....................................................................................................23
4.2.12 Potentiometer.................................................................................................23
4.2.13 LEDs ..............................................................................................................23
4.2.14 Push-button Switches ....................................................................................23
4.2.15 LCD Brightness Adjust...................................................................................25
4.2.16 16×2 LCD Module..........................................................................................25
5. Enhanced AgileHI D™ Protocol 3.0 27
5.1 Overview....................................................................................................................27
5.2 Protocol Functions.....................................................................................................27
5.2.1 Protocol API Use............................................................................................28
5.2.1.1 Master (Bridge)................................................................................28
4 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Contents
5.2.1.2 Slave (Mouse/Keyboard).................................................................28
5.2.2 Requirements.................................................................................................29
5.2.2.1 Header Files ....................................................................................29
5.2.2.2 Software Interface .............. ... ... .... ... ................ ... ... .... ... ................ ...29
5.2.3 Type Declarations and Definitions .................................................................29
5.2.3.1 BACK_CHANNEL_SUPPORT ........................................................29
5.2.4 Protocol High Level Functions.......................................................................29
5.2.4.1 MasterProtocolInit............................................................................29
5.2.4.2 MasterProtocolDataMode................................................................30
5.2.4.3 MasterProtocolButtonBindMode......................................................30
5.2.4.4 CheckUsbIdle..................................................................................31
5.2.4.5 CheckUsbSuspend..........................................................................31
5.2.4.6 SlaveProtocolInit..............................................................................32
5.2.4.7 SlaveProtocolSendPacket...............................................................32
5.2.4.8 SlaveProtocolGetTxPkt ...................................................................32
5.2.4.9 SlaveProtocolButtonBind.................................................................32
5.2.4.10 RadioSendPacket............................................................................33
5.2.4.11 RadioReceivePacket .......................................................................33
5.3 Application Packet Format.........................................................................................33
5.3.1 Mouse Application Packet Header Format ....................................................33
5.3.2 Keyboard Application Packet Header Format................................................33
5.3.2.1 Standard 101 Keys Report..............................................................34
5.3.2.2 Multimedia Keys ..............................................................................34
5.3.2.3 Power Keys .....................................................................................34
5.3.2.4 Battery Voltage Level and Version Report ......... ... .... ... ... ................34
5.3.2.5 Bridge Application Header Format ..................................................34
6. Example Proje cts 35
6.1 Theory of Operation.. .... ... ... ... ... .... ... ... ... ................. ... ... ... ... .... ................ ... ... ... .... ... ...35
6.1.1 Keyboard .......................................................................................................35
6.1.1.1 Firmware Block Diagram .................................................................35
6.1.1.2 Top Level Program Flow . ... ... ... .... ... ... ... ... .... ... ... ................ ... .... ... ...36
6.1.1.3 Code Details....................................................................................37
6.1.1.4 Keyboard Firmware Implementation................................................37
6.1.2 Mouse............................................................................................................39
6.1.2.1 Firmware Block Diagram .................................................................39
6.1.2.2 Top Level Program Flow . ... ... ... .... ... ... ... ... .... ... ... ................ ... .... ... ...40
6.1.2.3 Code Details....................................................................................41
6.1.2.4 Mouse Firmware Implementation ....................................................41
6.1.3 Bridge ............................................................................................................46
6.1.3.1 Firmware Block Diagram .................................................................46
6.1.3.2 Top Level Program Flow . ... ... ... .... ... ... ... ... .... ... ... ................ ... .... ... ...47
6.1.3.3 Code Details....................................................................................47
6.1.3.4 Bridge Firmware Implementation..... ... ... ... .... ... ... ... .... ... ... ... ... .... ... ...48
6.2 Setting up and Exercising Example Projects.............................................................49
6.2.1 Setting up WirelessUSB Keyboard......................... .... ... ... ... .... ................ ... ...49
6.2.2 Setting up WirelessUSB Bridge.....................................................................50
6.2.3 Exercising WirelessUSB Keyboard Example Project.....................................51
6.2.4 Setting up the WirelessUSB Mouse...............................................................52
6.2.5 Exercising WirelessUSB Mouse Example Project.........................................53
7. Troubleshooting 55
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 5
1. Introduction
The CY3668 Development Kit (DVK) User Guide allows you to develop wireless applications in a
2.4-GHz ISM band using Cypress’s WirelessUSB™-NL product.
1.1 Kit Contents
The CY3668 DVK includes:
■Two CY3668 bridge/keyboard development boards with integrated LCD panels
■Two WirelessUS B -NL modu le s
■Two CY3668-enCoRe V modules
■One CY3668-enCoRe II module
■Two 3.3-V LCDs
■Two powe r ad ap to rs
■One PSoC® MiniProg
■One USB A to Mini-B cable
■Ten connecting wire s
■Quick Start Guide
■Installation CD
1.2 PSoC Designer™ 5.3
Cypress's PSoC Designer is an easy-to-use software development integrated design environment
(IDE) that introduces a hard ware and sof tware co-design en vironment based on schematic entry and
embedded design methodology.
With PSoC Designer, you can:
■Automatically place and route select components an d integrate simple glue logic normally resid-
ing in discrete muxes.
■Trade off hardware and software design considerations allowing you to focus on what matters
and getting to market faster.
1.3 Additional Learning Resources
Visit http://www.cypress.com for additional learning resources in the form of datasheets, application
notes, and technical reference manual.
Introduction
6 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
1.4 Documentation Conventions
1.5 Document Revision History
Table 1. Documentation Conventions for User Guides
Convention Usage
Courier New Displays file locations, user ente red text, and source code:
C:\ ...cd\icc\
Italics Displays file names and reference documentation:
Read about the sourcefile.hex file in the PSoC Designer User Guide.
[Bracketed, Bold]Displays keyboard commands in procedures:
[Enter] or [Ctrl] [C]
File > Open Represents menu paths:
File > Open > New Project
Bold Displays commands, menu paths, and icon names in procedures:
Click the File icon and then click Open.
Times New Roman Displays an equation:
2 + 2 = 4
No text, gray table cell Represents a reserved bit in register tables.
Revision PDF Creation
Date Origin of
Change Description of Change
** 02/23/2012 CSAI Initial version of kit guide
*A 10/05/2012 SELV
Updated PSoC Designer version from 5.1 to 5.3
Modified sections Default Jumper Settings on page 9, Programming
Steps on page 10, and WUSB-NL Bridge Example on page 51
Organized the Installation chapter into Getting Started on page 7
and Kit Operation on page 9
Added Hardware on page 13 and Troubleshooting on page 55
*B 12/03/2012 SELV Updated directory path across the document.
*C 12/07/2012 SELV
Updated Programming Steps on page 1 0
Updated all procedures in chapter Example Projects on page 35
Added Sections Setting up WirelessUSB Bridge on page 50 and
Exercising WirelessUSB Mouse Example Project on page 53 .
*D 01/25/2013 SELV Updated Example Projects on page 35.
Updated Issue 4 in T roubleshooting on page 55.
Removed sample firmware code.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 7
2. Getting Started
This chapter describes the procedure to install the required tools and the software required to
program WirelessUSB-NL DVK.
2.1 Install Software
Follow these steps to install the re quired tools and software:
1. Insert the kit CD into the CD/DVD drive of your PC. The CD is designed to automatically invoke
the Kit Installer and the following installer screen appears.
Getting St arted
8 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Note If the installer is not automatically invoked, double-click cyautorun.exe in the ro ot dir ec to ry
of the CD as shown in the following screenshot.
2. Click 'Install WirelessUSB-NL DVK …' on the Installer screen and go through the installation pro-
cedure. This installs the following tools and software on your PC:
a. PSoC Designer
b. PSoC Programmer
c. WirelessUSB-NL DVK software
3. This completes the software installation process.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 9
3. Kit Operation
3.1 Install Hardware
WARNING: Static discharges from the human body can easily reach 20,000 volts. This can damage
the components on the DVK. Make sure that any static is discharged before touching the hardware.
Ensure the DVK is powered off before making any changes to the connections.
3.1.1 Default Jumper Settings
The following are the default jumper settings for both the CY3668 boards:
■J10 - place a jumper
■J2 - place a jumper between VREG and VDD
■J5 - place a jumper between pin 2 and 3.3 V
■J12 - place a jumper
■J6 - place a jumper between pins 2 and 3
■Leave other jumpers open
Figure 3-1. CY3668 Boards
Kit Operation
10 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
3.2 Programming and Emulation Procedures
Note You can program the kit using either the PSoC MiniProg or the ICE-Cube. However, the ICE-
Cube is requir ed f or e m ula tio n. T h e ICE- Cu be is available in th e PSoC De ve lo pm e nt Kit and can be
purchased from the Cypress's online store (PSoC Development Kit, CY3215-DK).
3.2.1 Programming Steps
Important
■Disconnect power supply from the 12-V power adapter.
■Remove the WUSB-NL module from the development board before programming the firmware.
■For the enCoRe V module, position the SW1 switch slider away from the LCD panel (see
enCoRe II/enCoRe V Programming Selector on page 19); for the enCoRe II module, position the
SW1 switch slider towards the LCD panel.
Follow these steps to program the kit:
1. Connect one end of the USB cable to th e PSoC MiniProg and the other end to the computer.
2. Connect the MiniProg to the 5-pin ISSP header on the CY3668 DVK board.
3. Launch PSoC Programmer version 3.16 or la ter.
4. If the Firmware Update required at ... dialog box is displayed, upgrade the MiniProg's firmware
by clicking Utilities > Upgrade Firmware before proceeding with the remaining steps.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 11
Kit Operation
Figure 3-2. PSoC Programmer
5. Click on File Load to load the desired binary (hex) file.
6. For Programming Mode, select Power Cycle.
7. Turn off AutoDetection.
8. Select the following part from the Device Family list based on the MCU module:
❐64300 for enCoRe V Module
❐63900 for enCoRe II Module
9. Select the following part from Device list based on the MCU module:
❐CY7C64300-48LTXC for enCoRe V Module
❐CY7C63923-PVXC for enCoRe II Module
10.Click Program. PSoC Programmer goes through programming and verification steps. Results
are displayed on th e bottom half of the screen.
11. Whe n prog ra m m ing is comp le te, remo ve th e Min iPr og fro m th e CY36 6 8 DVK bo ard.
Step 5
Step 10
Steps 8 and 9
Step 6
Step 7
12 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Kit Operation
3.2.2 Emulation Steps
1. Launch the desired .APP project file project from
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\<example
name>\[PSoC Project name]\.
2. Connect one end of the blue CAT 5e cable to the ICE-Cube.
3. Connect the other end of the CAT 5e cable to the CY3668 DVK board.
4. Select Build > Generate Configuration Files for '<Project name>' Project.
5. Select Build > Build '<Project name>' Project or press [F7].
6. Configure the debug port setting. Select Project > Settings > Debugger, then select ICE-Cube.
7. Select the Pod Power Source and Pod Supply Voltage.
a. If External only is selected, retain the default jumper setting.
b. If ICE may power pod is selected, choose 3.3 V as Pod Supply Voltage and pla ce a jumper
between VDD and VICE at J3.
Figure 3-3. PSoC Designer Toolbar
8. Select Debug > Connect, or select the Connect icon.
9. Select Debug > Download to Emulator, or select the Download to Emulator icon.
10.Select Debug > Go, press [F5], or select the Go icon.
Step#8
Step#9
Step#10
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 13
4. Hardware
4.1 System Block Diagram
The CY3668 DVK consists of the following blocks:
■Voltage Regulator and Power Supply Selection
■MCU Module (enCoRe II / enCoRe V)
■WUSB-NL Module
■LCD Module
■LEDs
■Reset, Push Buttons, and Potentiometer
■Bread Board Area
■USB Mini-B Interface
■Debug Port
■ISSP Interface
■I2C Interface
Figure 4-1. System Block Diagram
Hardware
14 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
4.2 Functional Description
Figure 4-2 shows the dif ferent functiona l blocks on the CY366 8 bridge/keyboard de velopment board.
Figure 4-2. CY3668 Development Board Functional Blocks
Voltage
Regulator
LCD Module
LCD Brightness
Adjust
Push-button
Switches
LEDs
Potentiometer
I2C Header
ISSP Header
Logic Analyzer
Header
MCU HeaderMCU Reset
Button
enCoRe II/enCoRe V
Program m ing S elector
ICE Header
USB Mini-B
Connector
W irelessUS B-N L
Radio Header
MCU Power
Selection
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 15
Hardware
4.2.1 Volt age Regulator
The following c ircuit diag ram show s the kit powe r supply design. On t he kit, the regulator is presen t
under the LCD module (you can unmount this module from the kit). There are four input sources to
the voltage regulator:
■Power jack Mini 0.08-inch RA PCMT connector
■MiniProg
■PSoC ICE
■USB mini-B connector
Figure 4-3. Voltage Regulator Circuit Diagram
The voltage regulator regulates the inputs mentioned earlier and provides a fixed 3.3-V output or an
adjustable volt age in the range 3.66 V to 1.63 V, depending on the J5 jumper and R5 ( potentiometer)
configuration. Table 4-1 gives details about how the different configurations can be achieved.
Note When using the adjustable power supply configuration of the kit, use a multimeter at TP3 to
monitor the output of the regulator.
Important Before changing any power supply configuration on the kit, first power off the kit and
unmount any MCU modules or WirelessUSB-NL modules on the kit. When all the power configura-
tions are fixed, remount all the necessary modules to resume operation.
Table 4-1. Volt age Regulator Configuration
Configuration Setting
3.3 V fixed J5: Short pins 2 and 3
Adjustable voltage from 3.66 V to 1.63 V J5: Short pins 1 and 2
Adjust the R5 potentiometer
16 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Hardware
4.2.2 MCU Power Selection
Figure 4-4. MCU Power Selection Circuit Diagram
Figure 4-4 shows the power selection jumper configuration for the MCU module. The MCU module
can be powered directly from any of the following voltage sources:
■Voltage regulator
■USB bus
■PSoC ICE
■MiniProg
Table 4-2 shows the configurations to select the different voltage sources.
Table 4-2. Voltage Source Configuration
Voltage Source Jumper Setting
Voltage regulator J2: Short pins 1 and 2
USB bus Short
J2: Pins 2 and 3
J12: Pins 1 and 2
PSoC ICE Short
J3: Pin 1
J2: Pin 2
MiniProg Short
J4: Pin 1
J2: Pin 2
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 17
Hardware
4.2.3 WirelessUSB-NL Radio Header
Figure 4-5. WirelessUSB-NL Interface Circuit Diagram
Figure 4-5 shows the WirelessUSB-NL radio header and other jumper settings in detail. By default,
port 2, bit 4 (P2.4) is connected to the WirelessUSB-NL radio reset through jumper J10. This jumper
will be populated (short) by default. Remove this jumper to disconnect P2.4 from the WirelessUSB-
NL reset. When disconnected, the WirelessUSB-NL reset can be reconnected to other port pins by
using jumper wires.
The J6 jumper pr ovides power to the ra dio modu le. By de fa ult, pins 2 an d 3 of J6 ar e shor te d. In this
configuration, the radio module is p owered fr om out put of volt a ge re gulator. The other ju mper se tting
possible is shorting pins 1 and 2 of jumper J6. In this configuration, the radio module can be pow-
ered from port 1, bit 2.
4.2.4 USB Mini-B Connecter
The kit can be powered using the USB bus power. This can be achieved by shorting pins 1 and 2 of
the J12 jumper. In this configuration, the kit can operate as a bus-powered device.
Figure 4-6. USB Connector and Power Jumper Circuit Diagram
18 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Hardware
4.2.5 ICE Header
The ICE-Cube debugger allows debugging and viewing the contents of specific memory locations.
The ICE-Cube debugger can be connected to the RJ45 connector on the board to connect to the
MCU with on-chip debugger (OCD) capability to enable debugging.
Figure 4-7. ICE Debug Header Circuit Diagra m
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 19
Hardware
4.2.6 enCoRe II/enCoRe V Programming Selector
Using the selector switch (SW1), you can choose between enCoRe V and enCoRe II modules for
programming. See Figure 4-8 for the MCU programming selector switch circuit diagram.
Figure 4-8. MCU Programming Selector Switch Circuit Diagram
The following programming configurations are possible through the selector switch:
■To program an enCoRe II module, position the slider of the switch away from the pin#1 of the
switch, as indicated in figure 9.
■To program an en CoRe V module, position the slider of the switch towards the pin#1 of the
switch, as indicated in figure 9.
Figure 4-9. Slider Orientation in Relation to Pin#1 for both MCUs
Slider Position
for enCoRe II Slider Position
for enCoRe V
20 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Hardware
4.2.7 MCU Header
Figure 4-10 shows the MCU header and connections. This kit support Cypress's enCoRe V and
enCoRe II MCUs via replaceable modules, which are supplied with this kit.
Cypress's enCoRe V Full-Speed USB peripheral microcontroller (MCUs) and enCoRe V LV (low-
voltage) wireless MCU provide the following capabilities:
■Up to 32 KB of flash memory
■Three 16-bit timers
■Up to 36 general-purpose I/Os (GPIOs) to accommodate enhanced multimedia features in
human interface devices (HIDs) .
The families are supported by the CY3668 enCoRe V/LV development kit, which shortens the design
time of laser mice, gaming controllers and keyboards, wireless dongles, remote controls, mobile
handset accessories, and point-of-sales devices.
The in-system reprogrammable enCoRe V and enCoRe V LV MCUs provide design flexibility with a
10-bit ADC, flash memory with EEPROM emulation, and small form-factor packages. The enCoRe V
devices also include eight USB endpoints. The enCoRe V LV family operates in the full range of
1.7 V to 3.6 V, with low power consumption for prolonged battery life in wireless applications, espe-
cially when paired with Cypress's low-power WirelessUSB-NL 2.4-GHz radio. All enCoRe MCUs
include Cypress's patented crystal-less oscillator and integrated pull-up resistor to reduce compo-
nent count and bill of material (BOM) cost.
The enCoRe II is a programmabl e low-spee d USB contro ller. It eliminates the exter nal crystal or res-
onator, pull-up resistors, wakeup circuitry, and 3.3-V regula tor to reduce the overa ll system co st. The
enCoRe II features a wide selection of I/O (up to 20 GPIOs) and memory (up to 8 KB of flash for user
code and 256 bytes of RAM) options targeted for USB applications. The enCoRe II LV is a low-volt-
age, low-cost 8-bit flash controllable microcontroller, bringing enhanced component reduction and
enCoRe II functionality to non-USB applications. By integrating an integrated oscillator, wakeup cir-
cuitry, and flash memory, enCoRe II LV helps to reduce the overall system costs.
22 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Hardware
4.2.9 Logic Analyzer Header
The logic analyzer header can be used for viewing different signals on an oscilloscope or the logic
analyzer. This interface enables hardware level debugging. Figure 4-12 shows the circuit diagram
for the header.
Figure 4-12. Logic Analyzer He ader Details
4.2.10 ISSP Header
In-system serial programmer (ISSP) is used to program the device using the MiniProg programmer
device and the USB cabl e. IS SP/I2 C pr og ra m mi ng is done thr ou gh th e 5- pin conne cto r.
Figure 4-13 shows the pin mapping for the ISSP connector.
Figure 4-13. ISSP Header Circuit Diagram
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 23
Hardware
4.2.11 I2C Header
The CY3668 development board is provided with an I2C connector.
Figure 4-14. I2C Header
4.2.12 Potentiometer
This potentiometer is used for varying the voltage to the ADC input. The output of the potentiometer
can be accessed from P10, pin 11. See Figure 4-15 on p age 24 for the circuit diagram.
4.2.13 LEDs
The LEDs provides a mechanism to indicate the firmware status. They are exposed via P10, pins 7
through 10. See Figure 4-15 on page 24 for the circuit diagram.
4.2.14 Push-button Switches
The switches provide firmware inputs to users. They are exposed via P10 pins 1 through 6. See
Figure 4-15 on page 24 for the circuit diagram.
24 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Hardware
Figure 4-15. Potentiometer, LEDs, and Switches
VDD
VDD
VDD
R31
POT 10K
R31
POT 10K
13
2
0805
R23 1K
0805
R23 1K
S2
SW PUSHBUTTON
S2
SW PUSHBUTTON
1A
1B
2A
2B
P10
RECETACLE 12X1
P10
RECETACLE 12X1
1
1
2
2
3
3
4
4
5
5
6
6
7
7
8
8
9
9
10
10
11
11
12
12
0805
R24 1K
0805
R24 1K
1206
D7
LED Yellow
1206
D7
LED Yellow
2 1
S4
SW PUSHBUTTON
S4
SW PUSHBUTTON
1A
1B
2A
2B
S1
SW PUSHBUTTON
S1
SW PUSHBUTTON
1A
1B
2A
2B
1206
D5
LED Green
1206
D5
LED Green
2 1
1206
D8
LED Yellow
1206
D8
LED Yellow
2 1
S3
SW PUSHBUTTON
S3
SW PUSHBUTTON
1A
1B
2A
2B
1206
D6
LED Green
1206
D6
LED Green
2 1
0805
R30 1K
0805
R30 1K
0805
R29 1K
0805
R29 1K
TP9TP9
S5
SW PUSHBUTTON
S5
SW PUSHBUTTON
1A
1B
2A
2B
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 25
Hardware
4.2.15 LCD Brightness Adjust
The contrast of the LCD can be varied using the LCD contrast potentiometer. See Figure 4-16 for the
circuit diagram.
4.2.16 16×2 LCD Module
The LCD interface connector is used to connect an LCD. It is a two-line 16-char acter LCD.
Figure 4-16. LCD Interface and Brightness Control
26 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Hardware
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 27
5. Enhanced AgileHID™ Protocol 3.0
5.1 Overview
The Enhanced AgileHID™ protocol is a proprietary wireless protocol developed by Cypress, specifi-
cally designed for human interface device (HID) applications such as wireless mouse and keyboard.
This protocol runs on Cypress's WirelessUSB-NL radio driver. Refer to the WirelessUSB-NL Radio
Driver API document that comes along with this kit for protocol requirement.
The Enhanced AgileHID protocol provides a set of application programming interfaces (APIs) to
develop wireless m ouse, keyboa rd, generi c devices, and bridg e (dongle) ap plications. Th is protocol
runs on Cypr ess's radio driver an d enCoRe II or enCoRe V controllers. The protocol is designed to
interface with C-based applications and consists of the following files:
■Protocol.c
■Protocol.h
■Usb.c (for bridge only)
■Usb.h (for bridge only)
Because the bridge is connected to the PC through USB, this protocol also u se s U SB d riv er API s t o
transfer packets to and from the PC. See the HID Spec ifications for USB driver requ ire m ents for this
protocol. This protocol also uses other controller peripherals (such as interrupt controllers, timers,
and GPIOs).
5.2 Protocol Functions
The following functionalities are visible to the application:
■Binding device (mouse/keyboard) with bridge connected to PC
■Packet transmit
■Packet receive
The following functionalities of the protocol are not visible to the application:
■Configuring transmit, receive, and transaction parameters
■Channel change algori thm to handle interference/noise
■Reconnect between device and bridge
■CRC generation
■Network ID generatio n
Enhanced AgileHID™ Protocol 3.0
28 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Figure 5-1. System Level Block Diagram
5.2.1 Protocol API Use
The protocol is divided into two modules: master protocol on the bridge and slave protocol on the
device (keyboard/mouse). Only one of the modules can be present in a subsys tem (either slave or
master protocol). The protocol module is selected using a define during the pre- co mp ila tion stage.
The protocol functions specific to a module are prefixed with the respective module name. For exam-
ple, the “protocol init” function 'MasterProtocolInit' for master and 'SlaveProtocolInit' for slave. Some
APIs are common to both the modules and are not prefixed with a module name.
5.2.1.1 Master (Bridge)
Initialization. Before the protocol is used, it must be first initialized using API MasterProtocolInit.
Configuration parameters are handled within the protocol and do not need to be passed.
Binding. This application uses the MasterProtocolButtonBindMode API to bind between the bridge
and the device. This function takes retry count as the p arame te r. Retry count refers to the number of
times the bridge waits for a bind request from the device.
Packet Polling and Processing. The function MasterProtocolDataMode is used to poll the packet
and to pass required data to the USB. This function abstracts all complex functionality of the protocol
such as channel hop, quiet channel detection, reconnecting to device, and so on. The response to
the device, if needed, is also handled within this function.
Bridge Suspend. The bridge decides to 'suspend' when it rece ives the suspend command from the
USB host. It also calls the RadioFor ceState API to fo rce the state to sleep. If the remote wakeup fea-
ture is enabled, the bridge goes to the radio packet receive mode periodically. After a packet is
received from a device, the application wakes up the USB.
5.2.1.2 Slave (Mouse/Keyboard)
Initialization. Before the protocol is used, it must be first initialized using the API SlaveProtocolInit.
Configuration parameters are handled within the protocol and do not need to be passed.
Binding. The device application uses SlaveProtocolButtonBind API to bind between the bridge and
the device. This function takes the device type as the parameter. The device is bound to the bridge
as this device type.
Transmission. The transmit buffer is maintained by protocol. The application uses the API Slave-
ProtocolGetTxPkt to get the buffer and fills it with the data to be transmitted. It uses the API Slave-
ProtocolSendPacket to transmit a packet. This API is a blocking API. This function internally
changes the channel and reconnects to a bridge during transmission failure.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 29
Enhanced AgileHID™ Protocol 3.0
Reception. According to the AgileHID protocol, the device is not expected to receive any packet
from the bridge. For keyboard applications, the back-channel-data packet is used by the protocol to
get some of the key status (such as Caps lock, Num lock, and Scroll lock) from the bridge. The sta-
tus of keys received from the bridge is stored in rx_packet.data.payload[0x0]. The first three bits in
this byte corres ponds to status of NUM LOCK , CAP LOCK, and SCRL LOCK respectively. The key-
board application is expected to implement a function "void NotifyDownloadBackChannelData
(void)". Base d on the key status p resent in rx_packet.data.payload[0x0], this function can make the
correspond in g LED glow.
5.2.2 Requirements
5.2.2.1 Header Files
To use the protocol, include protocol.h in any file that calls protocol functions.
5.2.2.2 Software Interface
The Enhanced AgileHID Protocol runs on Cypress's WirelessUSB-NL radio driver and PSoC
Designer USB User Module. It also uses some of the utility functions such as timer, flash read/write,
and so on. Typically, these utility functions along with sample mouse, keyboard, and bridge applica-
tions are provided along with the DVK; therefore, the user only needs to focus on the application.
5.2.3 Type Declarations and Definitions
5.2.3.1 BACK_CHANNEL_SUPPORT
This definition is needed by the protocol regardless of whether it requires backchannel support.
DEVICE_TYPE
typedef enum _DEVICE_TYPE
{
PRESENTER_DEVICE_TYPE = 0x00,
RESERVED_DEVICE_TYPE = 0x01,
KEYBOARD_DEVICE_TYPE = 0x02,
MOUSE_DEVICE_TYPE = 0x03,
}DEVICE_TYPE;
PROTOCOL_STATUS
typedef enum _PROTOCOL_STATUS
{
PROTOCOL_SUCCESS,
PROTOCOL_FAILED,
PROTOCOL_TX_TIMEOUT
} PROTOCOL_STATUS
5.2.4 Protocol High Level Functions
5.2.4.1 MasterProtocolInit
void MasterProtocolInit (void);
Parameters: None
Return Value: None
30 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Enhanced AgileHID™ Protocol 3.0
Description: This function initializes the Enhanced AgileHID protocol and is called during bridge
application initialization. Platform specific GPIO, SPIM, timer, and PSoC Designer USB User Module
initialization should be done before calling this function.
5.2.4.2 MasterProtocolDataMode
void MasterProtocolDataMode (void);
Parameters: None
Return Value: None
Description: This functio n checks if any pa cket is rece ived fr om the device. If received, it processes
the packet. The transfer of the HID packet to USB is internally done by this function. It also ensures
channel change in the event of a noisy environment. This function is continuously called by the
bridge application code.
5.2.4.3 MasterProtocolButtonBindMode
void MasterProtocolButtonBindMode(unsigned short retry_count)
Parameters: unsigned shor t retry_ co unt - Numb er of tim e s the brid ge chang es the ch ann el befor e it
times out.
Return Value: None
Description: The bridge application invokes this function when a bind event, such as bind button
press, occurs. In this API, the bridge protocol polls for the bind request in all the bind channels in a
periodic manner, as shown in Figure 5-2. It continues to poll for a bind request until it receives a bind
request or times out. From the device side, it transmits a bind request and waits for the bind
response. The device continues to do this in all the bin d channels in a round-robin man ner. The poll-
ing time slot of the bridge for ea ch channel is bi g enough to accommodate one cycle of device trans-
mitting connect request in all the channels. The device is bound to at least one channel assuming at
least one of the bind channels is quiet.
This function takes retry_count as a parameter to decide when to time out. The typical value is
around 65.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 31
Enhanced AgileHID™ Protocol 3.0
Figure 5-2. Bridge Protocol Polls for Bind Request
5.2.4.4 CheckUsbIdle
void CheckUsbIdle(void)
Parameters: None
Return Value: None
Description: This function is called by the bridge application to find out whether the USB bus is idle
for a specified time. If it is idle, then this function sends the last HID report to the USB host. This is to
emulate a wired HID .
5.2.4.5 CheckUsbSuspend
void CheckUsbSuspend(void)
Parameters: None
Return Value: None
Description: This function is called by the bridge ap plication to find out whe ther th e USB bus is sus-
pended. If it is suspended and remote wakeup is not enabled, then this function keeps the system in
sleep mode to save power. If remote wakeup is enabled, then this function sends a wakeup signal to
the USB host when a packet is received from the device.
Cycle 1 Cycle 2 Cycle 3
23.4 ms
Cycle 1000
23.4 ms x 1000 Cyles = 23. 4 s econds
Bridge
Device
Channel 0 Channel 6 Channel 12 Channel 78
1.8 ms 1.8 ms 1.8 ms
1.80 ms x 13 Chann els = 23.4 ms
Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle 5
4.16 s 4.16s x 5 Cycles ~ 21 seconds
Channel 0 Channel 6 Channel 12 Channel 7 2
320 ms 320 ms 320 ms
320 ms x 13 Channels ~ 4.16 seconds
Channel 78
Cycle 999
Channel 7 2
32 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Enhanced AgileHID™ Protocol 3.0
5.2.4.6 SlaveProtocolInit
void SlaveProtocolInit(void)
Parameters: None
Return Value: None
Description: This function initializes the Enhanced AgileHID protocol and is called during device
application initialization. Platform specific GPIO, SPIM, an d timer initialization must be done before
calling this function.
5.2.4.7 SlaveProtocolSendPacket
PROTOCOL_STATUS SlaveProtocolSendPacket (DEVICE_TYPE dev_type,
DEVICE_TYPE data_dev_type,
unsigned char data_length,
unsigned char back_channel
)
Parameters:
DEVICE_TYPE dev_type - Type of device
DEVICE_TYPE data_dev_type - Type of device in packet. Ex - keyboard trans-
mitting mouse packet.
unsigned char data_length - length of packet
unsigned char back_channel - flag. True if back channel data expected from
bridge.
Return Value: None
Description: This function is used by the device application to transmit a packet. The second
parameter decides the mouse or keyboard packet to be transmitted. The device application popu-
lates the buffer that it receives from the SlaveProtocolGetTxPkt API.
5.2.4.8 SlaveProtocolGetTxPkt
void * SlaveProtocolGetTxPkt (void)
Parameters: None
Return Value: Void * - pointer to the buffer where device application fills with data
Description: This function is called by the device application to know where to fill the data to be
transmitted.
5.2.4.9 SlaveProtocolButtonBind
void SlaveProtocolButtonBind (DEVICE_TYPE dev_type)
Parameters:
DEVICE_TYPE dev_type - Type of device with which it is bound to the bridge.
Return Value: None
Description: The device application invokes this function whenever a bind event such as bind but-
ton press occurs. In this API, the device continuously tries to bind to the bridge in all bind channels.
During binding, the device sends out a bind request to the bridge and waits for the bind response. If
it does not receive the r esponse, it continues to re peat it in all the bind ch an nels. See the descr iption
of MasterProtocolButtonBindMode on page 30.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 33
Enhanced AgileHID™ Protocol 3.0
5.2.4.10 RadioSendPacket
PROTOCOL_STATUS RadioSendPacket (unsigned char retry, unsigned char
length)
Parameters:
unsigned char retry - Number of times to retry transmission
unsigned char length - Length of the packet to be transmitted.
Return Value:
PROTOCOL_STATUS- PROTOCOL_SUCCESS, Transmission successful
- PROTOCOL_TX_TIMEOUT, Transmission failure
Description: This function is a generic function used by both the bridge and device (mouse/key-
board) to transmit a p acket. Typically, this function does not have to be called b y an application. If the
application wants to verify the basic transmit and receive functionalities, then this function can be
used. The application fills the data to be transmitted in the buffer it received from the API SlaveProt-
ocolGetTxPkt.
5.2.4.11 RadioReceivePacket
unsigned char RadioReceivePacket ( void )
Parameters: None
Return Value:
unsigned char- length of the packet received in bytes.
Description: This function is a generic function used by both the bridge and device (mouse/key-
board) to receive a packet. Typically, this function need not be called by an application. If the applica-
tion want s to veri fy the basic tr an smit an d r eceive functionalities, then this function can be used. The
received data is present in the protocol buffer (rx_packet.payload[]).
5.3 Application Packet Format
5.3.1 Mouse Application Packet Header Format
A typical three-button mouse application packet structure is shown in the following table. The packet
formats only show the application report payload and not the protocol packet format.
If there is no change in Z Delta and Button status, then the mouse application can send only two
bytes containing X and Y coordinates. The bridge can detect this based on the received packet
length. However, the button or Z Delta value alone cannot be sent. Instead , the X and Y Delta value
also should be sent keeping X and Y as zero.
5.3.2 Keyboard Application Packet Header Format
The first application report byte is Scan Code 1 if the byte is less than 0xF0. Otherwise, the first
application report byte is the Application Report Header (Multimedia, Power, Battery, or Keep Alive).
This also assumes that the multimedia and power keys do not use modifier keys and that 0xFF,
0xFE, 0xFD, and 0xFC are not valid Standard 101 key scan codes.
First Byte Second Byte Third Byte
X Delta Y Delta Z Delta [0:4] Buttons [5:7]
34 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Enhanced AgileHID™ Protocol 3.0
Trailing zeros in the reports are also removed to further minimize the number of bytes sent by the
radio.
The following section shows the keyboard packet. The packet formats only show the application
report payload and not the protocol packet format.
5.3.2.1 Standard 101 Keys Report
If the Application Report Header byte is less than 0xFC, then this indicates that this report is a Stan-
dard 101 Keys report and the first byte is the actual scan code rather than the report header. This is
done to optimize the packet size based on the fact that the most common report has only one non-
zero scan code without a modifier. The full Standard 101 Keys report format is as follows:
5.3.2.2 Multimedia Keys
An Application Report Header of 0xFF indicates that this report is a Multimedia Keys report. The
Multimedia Keys report format is as follows:
5.3.2.3 Power Keys
An Application Report Header of 0xFE indicates that this report is a Power Keys report. The Power
Keys report format is as follows:
5.3.2.4 Battery Voltage Level and Version Report
An Application Report Header of 0xFD indicates that this report is a Battery Voltage Level and Ver-
sion report. The Battery Voltage Level and Version report format are as follows:
5.3.2.5 Bridge Application Header Format
The packe ts re ceived from the device s are converte d to st andard HID p acket, which can be detected
by the HID class driver on the USB Host. For more details, see the HID specification.
First Byte Second Byte Third Byte Fourth Byte Fifth Byte Sixth Byte Seventh Byte
Scan Code 1
(<0xFC) Modifier Keys Scan Code 2 Scan Code 3 Scan Code 4 Scan Code 5 Scan Code 6
First Byte Second Byte Third Byte
Application Report Header (0XFF) Hot Key Scan Code ( upper 8 bits) Hot Key Scan Code ( lower 8 bits)
First Byte Second Byte
Application Report Header (0XFE) Power Key Scan Code
First Byte Second Byte Third Byte Fourth Byte Fifth Byte Sixth Byte
Application Report
Header (0XFD) Battery Voltage Level FW Version HW Version
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 35
6. Example Projects
The example projects that are provided with the kit demonstrate the basic functionality of a
WirelessUSB HID keyboard and mouse. The following sections describe the th eor y of opera tio n and
the procedure to exercise the keyboard and mouse example projects with a bridge. Two
development boards with WirelessUSB-NL radio modules are used. One board is used as a bridge,
which enumerates on the PC as a bus-powered USB composite device with two interfaces –
keyboard and mouse. The othe r board is used as a keyboard or as a mouse.
6.1 Theory of Operation
This section explains the design and imple mentation of wireless keyboard, mouse, and bridge exam-
ple project s. This includes th e softwa re block diagra m, flow chart, and deta ils about the key functions
that implement the application logic. These details help you to customize the example projects
based on your requirements.
6.1.1 Keyboard
6.1.1.1 Firmware Block Diagram
Figure 6-1. Keyboard Firmware Block Diagram
Keyboard Application
AgileHID Protocol
WirelessUSB-NL Driver
User Modules (SPI, Timer)
WirelessUSB-NLenCoRe V MCU
Firmware
Hardware
Example Projects
36 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
The firmware runs on an enCoRe V MCU, which is interfaced to WirelessUSB-NL over an SPI inter-
face. The firmware consists of the following three layers, apart from the standard PSoC Designer
features such as timers:
■WirelessUSB-NL Driver: This driver interfaces with the WirelessUSB-NL radio and provide s ini-
tialization, transmit, and receive APIs.
■AgileHID Protocol: This layer implements the Human Interface Device (HID) protocol, which
includes creation of HID packets using the keyboard inp ut data, binding, and an RF channel hop-
ping algorithm to handle RF interference. This layer accesses WirelessUSB-NL throug h the Wire-
lessUSB-NL Driver.
■Keyboard Application: This layer implements the keyboard application logic.
The following sections describe the implementation of the keyboard application to enable you to
customize the application logic based on your requirements. The remaining firmware layers
(WirelessUSB-NL Driver and Enhanced AgileHID protocol) are fixed and need not be changed.
6.1.1.2 Top Level Program Flow
The following flow chart describes the top level program flow implemented in the keyboard example
project.
Figure 6-2. Program Flow Chart
Start
Initialization
Is
bind button
pressed?
Initiate bind procedure
YES
Scan keyboard matrix for
any key press
NO
Has
any key
been pressed or
released?
YES
On key press generate
report and transmit over air
Has
‘keep alive’ timer
timeout?
Send corresponding
‘keep alive packet’ to
keep the RF link alive
YES
Enable
Interrupts
NO
Sleep On sleep timer interrupt
OR key press interrupt
NO
Disable interrupts
S0: Initialization
S2: Idle
S1: Active
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 37
Example Projects
6.1.1.3 Code Details
The keyboard application logic is implemented in keyboard.c and the main() function is located in
this file. This file is located at: <Install_Directory>\Cypress\CY3668 DVK\1.0\Firm-
ware\Keyboard\NL_Keyboard_enCoreV\NL_Keyboard_enCoreV\NL_Keyboard_enCoreV.
Note that the CY3668 DVK sof t ware is inst alled in the <Install_Diretory>. Fo r exampl e, it s typ-
ical location on a Windows 7 64-bit PC will be C:\Program Files (x86).
The following table lists the functions, which implement the application logic.
Table 6-1. Keyboard Code Details
6.1.1.4 Keyboard Firmware Implementation
The following figure shows details of the different states the keyboard firmware passes through.
Figure 6-3. Keyboard Firmware Flow
S0: Initia lization. When the keyboard is powered on, the firmware initializes different peripherals
(such as GPIOs, timers, debounce queue, LCD, and WirelessUSB-NL). This is done by the
KeyboardInit function. At the end of the keyboard initialization function, the message "WirelessUSB
NL Keyboard" is printed on the LCD panel.
S1: Active. In the next step, the keyboard scans if the bind button was pressed and released. In
this case the keyb oard goes into the bind mode. This is implemented by the ScanBindButton.
After this, the ScanKeyboard function helps to scan the keyboard. This function polls each of the
three lock buttons (switches) and updates their status. If any of the keys is pressed, that key is
added to the debounce queue and a counter is initialized. This is implemented by the Debounce
function. The value of this counter is determined by KEYBOARD_DEBOUNCE_COUNT. A keyboard
packet is sent to the bridg e only when the key remains pressed un til the counter reaches 0. Note that
File Functions
keyboard.c – implements a
polling based keyboard.
static void ScanBindButton(void);
static void DebounceInit(void);
static void AgeDebounceQueue(void);
static BOOL Debounce(UINT8 index);
static void SendKeyboardReport(UINT8 report_size, UINT8
protocol_device_type);
static void GenerateStandardReport(void);
static void GenerateReport(void);
static void ProcessColumn(UINT8 column_index, UINT8 *
current_key_state_ptr);
static void ScanKeyboard(void);
static void KeyboardInit(void);
Initialization
complete
S0 S1 S2
No key press or
keep alive timeout
Any key has been
pressed
38 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
in the example project only the three lock buttons are implemented while in a real application the
entire keyboard is scan ned in th e Sca nKeyb oa r d func t ion .
The information stored in the debounce queue is processed by GenerateReport, with the help of
GenerateStandardReport to generate an AgileHID keyboard packet. This report is sent to the bridge
by the SendKeyboardReport function, which in turn calls the SlaveProtocolSendPacket API of the
AgileHID protocol.
After a packet is transmitted, the keyboard tries to keep the radio link alive by transmitting 'Keep
Alive' packets. These packets are transmitted on regular intervals governed by
KEYBOARD_KEEP_ALIVE_TIMEOUT. If a key is kept pressed, the keyboard sends the corre-
sponding key code along with the 'Keep Alive' packet. The same occurs when a key is released;
however, there is a time limit, which is determined by KEY_UP_KEEP_LIVE_TIMEOUT.
Firmware keeps track o f the keys pr esent in the deboun ce qu eue by decr ementing the counter valu e
associated with each key. This is implemented in the AgeDebounceQueue function.
Figure 6-4. Flow Chart for Active State
S2: Idle. This section discusses the battery-saving aspect. After the processing described in the
previous sections is complete, the keyboard tries to sleep. This can happen on two occasions: first,
when a key is held down and second, when none of the keys are held down. In the first case, the
sleep period is governed by KEY_DOWN_DELAY_SAMPLE_PERIOD milliseconds. After this period
expires, the keyboard wakes up and sends the key again. Second, if no keys are pressed the key-
board goes to sle ep fore ver and wa kes up only on a GPIO interru pt (from a key) or a timer. On wake-
up, if no key press is detected the keyboard clears the watchdog timer and goes to sleep again. If
keys are presse d, th e firm wa r e sca ns the ke ys an d se nd s the rep o rt as men tio n ed abo ve .
Start
Scan keyboard matrix
Has any keys
been pressed or
released?
Add keys to
debounce queue
YES
Compile scan data in to
AgileHID packet and
transmit the same
NO
Age the debounce
queue (decrement
debouce counter)
Stop
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 39
Example Projects
6.1.2 Mouse
6.1.2.1 Firmware Block Diagram
Figure 6-5. Mouse Firmware Block Diagram
The firmware runs on an enCoRe V MCU, which is interfaced to WirelessUSB-NL over SPI interface.
The firmware consists of the following three layers, apart from the standard PSoC Designer features
such as timers:
■WirelessUSB-NL Driver: This driver interfaces with the WirelessUSB-NL radio and provide s ini-
tialization, transmit, and receive APIs.
■AgileHID Protocol: This layer implements the HID protocol, which includes creation of HID pack-
ets using mouse input data, binding, and an RF channel-hopping algorithm to handle RF interfer-
ence. This layer accesses WirelessUSB-NL through the WirelessUSB-NL driver.
■Mouse Application: This layer implements the mouse application logic.
The following sections describe the implementation of the mouse application to enable you to cus-
tomize the application logic based on your requirements. The remaining firmware layers (Wireles-
sUSB-NL Driver and Enhanced AgileHID protocol) are fixed and need not be changed.
Mouse Application
AgileHID Protocol
WirelessUSB-NL Driver
User Modules (SPI, Timer)
WirelessUSB-NLenCoRe V MCU
Firmware
Hardware
40 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
6.1.2.2 Top Level Program Flow
The following flow chart describes the top level program flow implemented in the mouse example
project.
Figure 6-6. Program Flow Chart
S4 : M ou s e O ff S ta te
Start
Initalization
Is
connection
successful?
YES
Process mouse events
and transmit reports
Is
idle timeout
triggered?
NO
Is
batte ry
low?
Tu rn o ff a ll
peripherals and
sleep forever YES
Sleep till new e ve n t a rri v es
(buttons, optical sensor, wheel)
YES
On peripheral
interrupt
S2: Mouse Active State
S3: Mouse Idle State
Is
bind button
pressed?
NO
Attempt connection to
bridge
S1: Mouse Disconnected State
NO
Initiate b ind
process
YES
NO
S0: Init ia lization
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 41
Example Projects
6.1.2.3 Code Details
The mouse application logic is implemen ted in mouse.c and the main( ) fun ction is located in this file.
This file is located at <Install_Directory>\Cypress\CY3668 DVK\1.0\Firm-
ware\Mouse\NL_Mouse_enCoreV\NL_Mouse_enCoreV\NL_Mouse_enCoreV. Note that the
CY3668 DVK software is installed in the <Install_Diretory>. For example, its typical location
on a Windows 7 64-bit PC will be C:\Program Files (x86).
The following table lists the functions, which implement the application logic.
Table 6-2. Mouse Code Details
6.1.2.4 Mouse Firmware Implementation
The mouse firmware is a state machine implementation with the following states.
■S0: Initialization
■S1: Disconnected
■S2: Active
■S3: Idle
■S4: Off
The following figure shows d etails of the state machine implementation.
File Functions
mouse.c – implements a state
machine that will simulate a three
button mouse.
void main(void)
static void MouseInit(void)
static void MouseGoDisconnected(void)
static void MouseGoActive(void)
static void MouseGoIdle(void)
static void MouseGoOff(void)
static void MouseDoBind(void)
static void MouseDoReport(void)
static void MouseDoBattLevel(void)
static void MouseDoLowVoltage(void)
BOOL MouseGetReport(TX_PACKET *packet)
void RetrieveGloabSystemParameters(void)
void StoreGloabSystemParameters(void)
42 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
Figure 6-7. Mouse Firmware Flow
Most of the code in main.c and in other application files implements this state machine. To help you
understand the firmware better, this section explains what each state does and the corresponding
functions used to implement that state.
Initialization state (S0). On power-up, the mouse firmware initializes the various resources used.
These resources include ports, interrupt service routines, timers, optical sensor, buttons, scroll
wheel, SPI master, and radio. After all these resources are initialized , the LCD module display s the
message "WirelessUSB-NL Mouse". During initialization the SPI Master User Module is set to mode
1 and MSB first configuration. The MouseInit function performs this initialization.
Disconnected state (S1). After all initializations are over, the mouse goes into the disconnected
state (S1). The disconnected state is implemented by the MouseGoDisconnected function. The
mouse sleeps for a specified time given by the MOUSE_DISCONNECTED_POLL_MS macro or
until some kind of interrupt (such as a senso r, scroll wheel, or button inte rrupt) ha ppens. In th is case,
each interrupt is considered as an event and information regarding this is stored in mouse_event.
These mouse events are updated by corresponding ISRs present in the isr.c. This kind of sleep or
wait is achieved by the TimerWaitEvent function.
When the firmware wake s up due to a n e xpire d time r o r interr up t, it checks for a b i nd bu tton press. If
the bind button is pressed and released, the mouse performs a bind operation. These actions are
performed by the MouseDoBind function.
The next step is to try and connect to the bridge to which the mouse is bound. This connection
request is initiated by calling the SlaveProtocolSendPacket with no payload. If the protocol makes a
successful connection with the bridge, the mouse changes its state to active
(MOUSE_STATE_ACTIVE). If the connection is unsuccessful, the mouse checks for low battery. If
low battery is detected, it goes to MOUSE_STATE_OFF; otherwise it goes to sle ep. Th ese steps are
repeated until a connection is successfully established.
Initialization
complete
S0 S1 S2 S3
S4
Connection
to bridge Activity
timeout
Low battery
Low batteryLow battery
Disconnection
from bridge Interrupt (GPIO / Timer)
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 43
Example Projects
Figure 6-8. Flow Chart for Disconnected state
Active state (S2). The active state (S2) is entered only if there is a successful connection to the
bridge or if there are any new events to report. The active state is implemented by the
MouseGoActive function. In the active state, you must first check if there is enough power left in the
battery. If the battery has low power, the mouse changes to the off state (MOUSE_STATE_OFF).
This is achieved by the MouseDoLowVoltage function.
Next, the mouse generates and trans mits re ports for the new event s that happened . This is achieved
through the MouseDoRepo rt function. MouseDoRep ort gather s the st at e of each pe ripheral ( such as
sensor, scroll wheel, and button interrupt) by calling the MouseGetReport function. MouseDoReport
compiles this into an AgileHID packet and transmit s it over the air through the protocol call SlavePro-
tocolSendPacket.
After all the events are processed, the mouse checks for the battery voltage level. The measured
battery voltage levels are transmitted to the bridge. This is achieved through MouseDoBattLevel.
This feature of the firmware can be turned off by undefining the MOUSE_BATTERY_STATUS
macro. By default this feature is turned off.
The next step checks if the bind button was pressed and released. If this event is detected, the
mouse performs a bind operation. These actions are performed by the MouseDoBind function.
After all the tasks are performed, the mouse waits (sleeps) for MOUSE_REPORT_IN_MS time. This
wait time ensures the mouse maintains a specific report rate. Report rate is the number of reports
that the PC receives from a mouse every second. By default this wait period is set to 6 ms to ensure
a report rate of approximately 125. Increasing this interval lowers the report rate and decreasing this
interval raises the report rate. The limitation of a low-speed bridge (enCoRe II) is that it can only
maintain a report rate of 125. However, a full-speed bridge (enCoRe V) can do reports up to 1000
per second. If the mo use is bou nd to a low-sp eed br idge, it is beneficial (in terms of power consump-
tion) to maintain a report rate of around 125 and sleep for rest of the time.
Start
Sleep for
MOUSE_DISCONNECTED_POLL_MS
time or untill event arrives
On bind button press and release
perform bi nd op erat i on
Is bridge
present?
Is battery low? NO
Change state to
MOUSE_STATE_ACTIVE
YES
NO
Change state to
MOUSE_STATE_OFF
YES
Stop
44 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
After the r eport interval timeout, th e mouse goes back an d does all the actions mentioned in this sec-
tion. This process continues until there are no more events to be reported. Because there are no
more events to report, th e mouse co unts down MOUSE _ACTIVE_M S. At the en d of this coun tdown
the mouse goes to the idle st ate. By default MOUSE_ACTIVE_MS is 8000 ms.
Figure 6-9. Flow Chart for Active State
Start
Check battery voltage
Is battery low?
Generate reports based on events and
transmit them over the air
NO
Check bat t ery volta ge level and
transmit to bridge if there is a change
On bind button press and release
perform bi nd ope ra t i oi n
Has
MOUSE_ACTIVE_MS
elapse d with no
events?
Is next
report due?
NO
Sleep for
MOUSE_REPORT_IN_MS
NO
YES
Change state to
MOUSE_STATE_IDLE
YES
Change state to
MOUSE_STATE_OFF YES
Stop
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 45
Example Projects
Idle State (S3). If the mouse is inactive and there are no events to report to the bridge for
MOUSE_ACTIVE_MS time, then the mouse goes into the idle state. In the idle state the mouse
sleeps for 65535 ms, waking up in between only for events such as a timer interrupt or GPIO inter-
rupt. Ideally the mouse will sleep forever but the timer has a 16-bit limit. Due to this limitation the
mouse wakes up every 65535 ms, checks the battery level, and then goes back to sleep. If there is
any activity or event (su ch as a timer interrupt or a GPIO interrupt) during this state, the mouse state
is changed to MOUSE_STATE_ACTIVE and goes to the active state. The idle state is imple mented
by the MouseGoIdle function.
Figure 6-10. Flow Chart for Idle State
Off State (S4). The mouse enters this state only if the battery voltage is too low for the device to
operate. In this case the mouse turns off all peripherals and goes to sleep forever. The device
remains in this s tate until the batteries are replac ed. This state is implemented by the MouseGoOff
function.
Figure 6-11. Flow Chart for Off State
Start
Sleep until even occurs or
65535 ms timer expires
Wake
caused by
timer?
Change state to
MOUSE_STATE_ACTIVE
NO
Check battery voltage
YES
Is battery low?
Change state to
MOUSE_STATE_OFF
YES
NO
Stop
Start
Clear watchdog
timer and sleep
46 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
6.1.3 Bridge
6.1.3.1 Firmware Block Diagram
Figure 6-12. Bridge Firmware Block Diagram
The firmware runs on an enCoRe V or enCoRe II MCU, which is interfaced to WirelessUSB-NL over
SPI interface. The firmware consists of the following three layers, apart from the standard PSoC
Designer features such as timers:
■WirelessUSB-NL Driver: This driver interfaces with the WirelessUSB-NL radio and provide s ini-
tialization, transmit, and receive APIs.
■AgileHID Protocol: This layer implements the HID protocol, which includes reception of HID pack-
ets from a mouse and keyboard, binding, and an RF ch annel-hopping algorithm to handle RF
interference. This layer accesses WirelessUSB-NL through th e Wirele ssUSB-NL driver.
■Bridge Application: This layer implements the bridge application logic.
The following sections describe the implementation of the bridge application to enable you to cus-
tomize the application logic based on your requirements. The remaining firmware layers (Wireles-
sUSB-NL Driver and Enhanced AgileHID protocol) are fixed and need not be changed.
Bridge Appli c ation
AgileHID Protocol
WirelessUSB-NL Driver
User Modules (SPI, Timer, USB)
WirelessUSB-NL
enCoRe V /
enCoRe II MCU
Firmware
Hardware
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 47
Example Projects
6.1.3.2 Top Level Program Flow
The following flow chart describes the top level program flow implemented in the bridge example
project.
Figure 6-13. Top Level Program Flow
6.1.3.3 Code Details
The bridge application logic is implemented in bridge.c and usb.c. The main() function is located in
the bridge.c file. For the enCoRe V bridge, these files are located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Bridge\NL_Bridge_enCo
reV\NL_Bridge_enCoreV\NL_Bridge_enCoreV. For the enCoRe II bridge, these files are
located at <Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Bridge\NL_Bri
dge_enCoreII\NL_Bridge_enCoreII\NL_Bridge_enCoreII.
Note that the CY3668 DVK software is installed in the <Install_Directory>. For example, its
typical location on a Windows 7 64-bit PC will be C:\Program Files (x86).
The following table lists the functions, which implement the application logic. There is no difference
in the implementation details of the enCoRe II and the enCoRe V bridge.
Start
Initialize (USB, timer and
WirelessUSB-NL) and enumerate
Is
USB idle timer
expired?
Put radio in receive mode
NO
Process receiv ed data and
transfer through USB to host
Suspend USB and sleep till
activity detected on USB or
over the air YES
S0: Initialization
S2: Suspend
S1: Active
48 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
Table 6-3. Bridge Code Details
Note that the only difference between the enCoRe II and enCore V firmware is that enCoRe II firm-
ware does not display any content on the LCD panel.
6.1.3.4 Bridge Firmware Implementation
The following figure shows details of the different states the bridge firmware passes through.
Figure 6-14. Bridge Firmware Flow
S0: Initia lization. On plugging into the USB port, the bridge initializes the different peripherals
required. The different peripherals include USB, timers, an d the WirelessUSB-NL radio . In the case
of enCoRe V brid ge, the LCD panel is also initialized and the message "WirelessUSB-NL Bridge" is
displayed on it. The initialization is achieved by the BridgeInit function. The initialization function is a
blocking function because of USB enumeration and LCD in the case of the enCoRe V bridge.
S1: Active. After the initialization is complete, the bridge c hecks if the USB bus is idle. This is imple-
mented by CheckUsbIdle. The CheckUsbIdle checks for end point availability. If an end point is
available for transaction, the bridge loads a packet received from any of the devices (mouse and
keyboard) to the end point.
The next action is to listen for more radio packets from the mouse or keyboard. This is achieved
through the MasterProtocolDataMode. This function is part of the AgileHID protocol and has call-
backs that are implemented by the application layer. These call-back functions are called if a packet
is received either from the mouse or the keyboard. The two call-back functions are
handle_keyboard_report and handle_mouse_report. The handle_keyboard_report is called if a key-
board packet is received and the handle_mouse_report is called if a mouse packet is received.
These functions extract data from the AgileHID radio packets and compile it to a USB HID packet.
These packets are, in turn, reported through the USB via CheckUsbIdle.
After all the received radio packets are dispatched accordingly, the bridge checks for the bind button
event (press and release of the bind button). On this event, the bridge goes into the bind mode by
calling the AgileHID MasterProtocolButtonBindMode API. The bind process is handled by the
CheckBindButton in the bridge code.
File Functions
bridge.c – implements a unified bridge for
both keyboard and mouse. This application
acts as a bridge between the wireless device
(i.e. mouse / keyboard) and the USB port of
a PC / laptop.
void main(void)
void CheckBindBut to n( void)
void BridgeInit(void)
usb.c – implements USB reporting functions.
UINT8 handle_keyboard_report(void)
UINT8 handle_mouse_report(void)
void CheckUsbSuspend(void)
void CheckUsbIdle(void)
Initialization and
enumeration
complete
S0 S1 S2
Host suspend
On keyboard / mouse packet
reception
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 49
Example Projects
S2: Suspend. The firmware then checks USB_ACTIVITY_TIMEOUT_COUNTER. If the value of
this counter is 0, then the firmware pu ts the device in USB suspend state by initiating sleep. This is
implemented in Ch eckUsbSuspend . The value of the USB_ACTIVITY_TIMEOUT_COUNTER is set
to 3 ms according to the USB specification, which requires devices to go to low-power state when no
activity happens on the USB bus for 3 ms. When the bridge comes out of susp end du e to the activity
on the USB bus, the USB_ACTIVITY_TIMEOUT_COUNTER is re-initialized to 3 ms.
6.2 Setting up and Exercising Example Projects
6.2.1 Setting up WirelessUSB Keyboard
1. Open the WirelessUSB Example keyboard project in PSoC Designer . The project file is located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Keyboard
\NL_Keyboard_enCoreV\NL_Keyboard_enCoreV.app.
2. Go to Project > Settings > Compiler to choose the applicable compiler.
3. Select Build > Generate Configuration Files for 'NL_Keyboard_enCoReV' Project.
4. Build the project. Select Build > Build 'NL_Keyboard_enCoReV' Project or press [F7].
5. Because the enCoRe V module is u sed, position the SW1 switch slider away from the LCD panel
(see enCoRe II/enCoRe V Programming Selector on page 19).
6. After the build process is successful, the output hex file is located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Keyboard\
NL_Keyboard_enCoReV\NL_Keyboard_enCoReV\NL_Keyboard_enCoReV\output.
7. Download the built firmware (hex file) on the CY3668 Development Board by following the Pro-
gramming Steps on page 10.
Note Make sure to remove the power source (12- V power adapter or USB cable) from the
CY3668 Development Board before proceeding with the remaining steps.
8. Attach the WirelessUSB-NL Radio module to P2.
9. Wire up button S5 as a bind bu tton. On the CY3668 DVK board, a ttach a wire from P0_6 on P7 to
S5 on P10.
10.Wire up button S1 as Num Lock key, button S2 as Caps Lock key, and button S3 as Scroll Lock
Key. On the CY3668 DVK board, attach wires from P0_3 on P7 to S1 on P10, fr om P0_4 on P7 to
S2 on P10, and from P0_5 on P7 to S3 on P10 separately.
11.Wire up LED1 as Num Lock LED, LED2 as Caps Lock LED, and LED3 as Scroll Lo ck LE D. On
the CY3668 DVK board, attach wire s from P0_0 on P7 to LED1 on P10, from P0_1 on P7 to
LED2 on P10, and from P0_2 on P7 to LED3 on P10 separately.
12.Place a two-pin jumper on J10 for selecting the NL_RST pin to P2_4 for enCoRe V.
13.Place a two-pin jumper on J6 connecting VRADIO and VREG.
14.Place a two-pin jumper on J2 and J3 connecting VDD and VREG.
15.J5 is used to select the fixed 3.3 V VREG or adjustable VREG from 3.66 V to 1.63 V. In this
example, it is suggested to use fixed 3.3 V VREG.
16.Connect the 12 V power adapter to P1.
50 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
Figure 6-15. WUSB-NL Keyboard Example
6.2.2 Setting up WirelessUSB Bridge
1. Open the NL_Bridge_enCoReV bridge project in PSoC Designer. The project file is located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firm-
ware\Bridge\NL_Bridge_enCoReV\NL_Bridge_enCoReV.app. Note that
<Install_Diretory> is the directory under which CY3668 DVK Software is installed during
Installation process. For example, its typical value on a Windows 7 64 bit PC shall be C:\Pro-
gram Files (x86).
Note Use NL_Bridge_enCoReII to test the bridge code for the enCoRe II device.
2. If enCoRe V module is used, position the SW1 switch slider away from the LCD panel (see
enCoRe II/enCoRe V Programming Selector on p age 19); for enCoRe II module, position SW1
switch slider towards the LCD panel.
3. Go to Project > Settings > Compiler and select the Imagecraft compiler.
4. Select Build > Generate Configuration Files for 'NL_Bridge_enCoReV' Project.
5. Build the project. Select Build > Build 'NL_Bridge_enCoReV' Project or press [F7].
6. After the build process is successful, the output hex file is located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Bridge\
NL_Bridge_enCoReV\NL_Bridge_enCoReV\ NL_Bridge_enCoReV\output.
7. Download the built firmware (hex file) on the CY3668 Development Board by following the Pro-
gramming Steps on page 10.
Note Make sure to remove the power source (12-V power adapter or USB cable) from the
CY3668 Development Board before proceeding with the remaining steps.
8. Attach the WirelessUSB-NL Radio module to P2.
9. Wire up button S1 as Bind button. On the CY3668 DVK board, attach a wire from P0_3 on P7 to
S1 on P10.
10.Wire up LED1 and LED2. On the CY3668 DVK board, attach wires from P0_0 on P7 to LED1 on
P10 and from P0_1 on P7 to LED2 on P10 separately.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 51
Example Projects
11.Place a two-pin jumper on J12.
12.Place a two-pin jumper on J10 for selecting the NL_RST pin to P2_4 for enCoRe V. If an
enCoRe II module is used for testing, do not place this jumper; instead use an external wire
between P0_7 and NL_RST (in P6).
13.Place a two-pin jumper on J6 connecting VRADIO and VREG.
14.Place a two-pin jumper on J2 and J3 connecting VDD and VREG.
15.J5 is used to select the fixed 3.3 V VREG or adjustable VREG from 3.66 V to 1.63 V. In this
example, it is suggested to use a fixed 3.3 V VREG.
16.Connect the mini-B side of the USB A/Mini-B cable to the CY3668 DVK board.
17.Connect the A side of the USB A/Mini-B cable to the PC.
18.The NL_Bridge_enCoReV bridge should enumerate on the PC as a composite USB device sup-
porting both keyboard and mouse.
Figure 6-16. WUSB-NL Bridge Example
6.2.3 Exercising WirelessUSB Keyboard Example Project
1. Press S1 on the Develop ment Boa rd running th e Bridge fir mware to change to bind mode. LED1
on the Bridge blinks to denote bind mode. Press S5 on the Development board runn ing Keyboard
firmware to change to bind mo de; wait for 2 seconds. On su ccessful binding, LED1 on the Bridge
switches off and the wir eless link is now ready for data transfer.
2. On the Development Board running Keyboard firmware, press S1 for Num Lock, S2 for Caps
Lock, and S3 for Scroll Lock. The actions corresponding to the pressed key is executed on the
PC.
52 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
6.2.4 Setting up the WirelessUSB Mouse
1. Open the WirelessUSB example mouse project in PSoC Designer. The project file is located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Mouse\
NL_Mouse_enCoReV\NL_Mouse_enCoReV.app.
2. Go to Project > Settings > Compiler to choose the applicable compiler.
3. Select Build > Generate Configuration Files for 'NL_Mouse_enCoReV' Project.
4. Build the project. Select Build > Build 'NL_Mouse_enCoReV' Project or press [F7].
5. Because enCoRe V module is used, position the SW1 switch slider away from the LCD panel
(see enCoRe II/enCoRe V Programming Selector on page 19).
6. After the build process is successful, the output hex file is located at
<Install_Directory>\Cypress\CY3668 DVK\1.0\Firmware\Mouse\
NL_Mouse_enCoReV\NL_Mouse_enCoReV\ NL_Mouse_enCoReV\output.
7. Download the built firmware (hex file) on the CY3668 Development Board by following the Pro-
gramming Steps on page 10.
Note Make sure to remove the power source (12-V power adapter or USB cable) from the
CY3668 Development Board before proceeding with the remaining steps.
8. Attach the WirelessUSB-NL Radio module to P2.
9. Wire up S5 as the Bind Button. On the CY3668 board, connect a wire between P0[6] in P7 and
S5 on P10.
10.Wire up S1 as the left button of the mouse, S2 as the right butt on , S3 as th e mid d le bu tto n , and
S4 as the movement button on the CY3668 board.
a. Connect a wire from P0[0] in P7 to S1 in P10 for left button
b. Connect a wire from P0[1] in P7 to S2 in P10 for right button
c. Connect a wire from P0[2] in P7 to S3 in P10 for middle button
d. Connect a wire from P0[3] in P7 to S4 in P10 for movement button
11.Place a two-pin jumper on J6 between pins 2 and 3.
12.Place a two-pin jumper on J2 and J3 connecting VDD and VREG.
13.J5 is used to select the fixed 3.3 V VREG or adjustable VREG from 3.66 V to 1.63 V. In this
example, it is suggested to use fixed 3.3 V VREG.
14.Connect the 12-V power adapter to P1.
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 53
Example Projects
Figure 6-17. WUSB-NL Mouse Example
6.2.5 Exercising WirelessUSB Mouse Example Project
1. Press S1 on the Bridg e to chang e to bind mod e. LED1 on the Bridge blinks to denote b ind mode.
Press S5 on the Development Board running the Mouse firmware to change to bind mode; wait
for 2 seconds. On successful binding, LED1 on the Bridge switches off and the wireless link is
now ready for data transfer.
2. On the Development Board running Mouse firmware, press S1 for Left Button Click, S2 for Right
Button Click, and S3 for Middle Button Click. The ac tions corresponding to the pressed key is
executed on the computer. Press S4 to send simulated circular optical sensor movement to the
PC. This will result in mouse pointer moving in circular fashion on the PC.
54 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
Example Projects
WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D 55
7. T roubleshooting
1. Issue: Unable to download firmware to enCoRe II module after plugging it on the development board.
Fix: Switch SW1 determines the MCU type (enCoRe V LV/enCoRe II) to be used on a given develo pment board. To select
enCoRe II, ensure that the switch is pushed towards the LCD panel. See enCoRe II/enCoRe V Programming Selector on
page 19 for details.
2. Issue: Firmware does not come up after plugging in the WUSB-NL module.
Fix: Make sure all 10 pins of the WUSB-NL modu le are plugged on to the 10 pins of the socket locate d on the development
board and are properly aligned.
Figure 7-1. WirelessUSB-NL Module Plugged-in Incorrectly
3. Issue: Text displayed on the LCD display area is not clear or is not visible.
Fix: The rotary knob located below the LCD controls the contrast of the LCD display. Turn the knob in the clockwise direction
to increase the contrast of the LCD screen. Set the contrast to a level of your choice.
Figure 7-2. LCD Brightness Control
Rotary Knob
Troubleshooting
56 WirelessUSB-NL Development Kit Guide, Doc. # 001-76173 Rev. *D
4. Issue: Development board is not powered using the USB cable.
Fix: Position of jumpers at J2, J3, and J4 determine the power source mechanism for the development board. To power using
the USB cable, short pins 2 and 3 of J2 and pins 1 and 2 of J12. See MCU Power Selection on page 16 for details.
5. Issue: Not able to send data from Keyboard Development Board to Bridge Development Board.
Fix: For data transfer to happen, the Keyboard should successfully bound to the Bridge. If the data transfer does not happen,
the binding process may not be successful. Please follow this procedure to bind to the bridge.
■Place Bridge Development Board and Keyboard Development Board close to each other (within one meter distance)
■Power On the Bridge and the Keyboard
■Press S1 button on Bridge. Confirm that LED1 on Bridge is blinking continuously.
■Press S5 button on Keyboard.
■Wait for LED1 on Bridge to go off in around 2 seconds.
■Keyboard is now successfully bound to the Bridge.
If the LED1 on the Bridge does not go off in a few seconds, repeat this procedure.
