CY4672 Reference Design Guide Document # 001-16968 Revision ** Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone (USA): 800.858.1810 Phone (Intnl): 408.943.2600 http://www.cypress.
Copyrights Copyrights © Cypress Semiconductor Corporation, 2007. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights.
Contents 1. Introduction 1.1 1.2 1.3 1.4 Scope...........................................................................................................................9 Chapter Overviews .....................................................................................................9 Support ........................................................................................................................9 Conventions.............................................................................
Contents 3. Mouse 3.1 3.2 3.3 4 33 Introduction................................................................................................................33 3.1.1 Design Features ............................................................................................ 33 Hardware Overview ................................................................................................... 33 3.2.1 RDK Mouse Assembly ..................................................................................
Contents 3.3.8 3.3.9 3.4 Initialization ....................................................................................................47 Wireless Protocol Data Payload.....................................................................47 3.3.9.1 Packet Format 1...............................................................................48 3.3.9.2 Packet Format 2...............................................................................48 3.3.9.3 Packet Format 3...............................
Contents 4.4 4.5 5. Bridge 5.1 5.2 5.3 6 4.3.6.10 KEYBOARD_TX_TIMEOUT............................................................ 64 4.3.6.11 TIMER_CAL .................................................................................... 64 4.3.6.12 ENCRYPT_TEA .............................................................................. 64 4.3.6.13 ENCRYPT_AES .............................................................................. 64 4.3.6.14 MFG_TEST_CODE .....................................
Contents 5.3.4.5 Master Protocol................................................................................83 Application Code ............................................................................................83 5.3.5.1 Bridge Module..................................................................................83 5.3.5.2 USB Module.....................................................................................84 5.3.5.3 Mfgtest Module .................................................
Contents 7. Regulatory Testing Results 7.1 8. Power Considerations 8.1 8.2 9.3 8 107 RDK Keyboard.........................................................................................................107 8.1.1 Usage Model................................................................................................107 8.1.2 Current Measurements ................................................................................107 8.1.3 Battery Life Calculations .......................................
1. 1.1 Introduction Scope This document was written for firmware and hardware developers that want to understand and make modifications to the PRoC™ LP KBM Reference Design Kit (RDK). This document provides a description of the hardware along with architecture and configuration options for the PRoC LP KBM RDK. 1.2 Chapter Overviews Table 1-1. Overview of the CY4672 Reference Design Guide Chapters Chapter Introduction (on page 9) WirelessUSB™ Protocol 2.
Introduction 1.4 Conventions The following are easily identifiable conventions used throughout this user guide. Table 1-2. Documentation Conventions Convention Courier New Size 12 Italics [bracketed, bold] File > New Project Bold 1.4.1 Usage Displays file locations and source code: C:\ …cd\icc\, user entered text. Displays file names and reference documentation: sourcefile.
Introduction Table 1-3. Acronyms (continued) Acronym RDK RSSI SOP TEA USB WirelessUSB Description reference design kit; it is produced by Cypress Semiconductor and used by third parties to produce off-the-shelf products. Everything required to take a product to production is included in the kit.
Introduction 12 CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
2. 2.1 WirelessUSB™ Protocol 2.2 General Overview The WirelessUSB™ protocol 2.2 is designed to address 2-way Human Interface Devices (HID) as well as general purpose devices; it provides reliable 2-way communication between a wireless device configured as 1:1 (one HID and one bridge) or 2:1 (two HIDs and one bridge) systems. The WirelessUSB protocol 2.2 allows HID applications to establish a connection to the bridge and receive ACK and DATA packets from the bridge. Figure 2-1.
WirelessUSB™ Protocol 2.2 accommodate hundreds of WirelessUSB devices in the same space. Each bridge/HID pair must use the same PN code and channel in order to communicate with each other. 2.1.3 Chip Error Correction In the presence of interference (or near the limits of range), the transmitted PN code will often be received with some PN code chips corrupted. DSSS receivers use a data correlator to decode the incoming data stream.
WirelessUSB™ Protocol 2.2 2.1.7 Channel Selection Algorithm The channel selection algorithm produces a subset containing 13 of the possible 78 channels. The channel selection algorithm is based on the network ID, with each channel in the subset being six megahertz from the nearest neighboring channels in the subset. This algorithm reduces the possibility of multiple bridges selecting the same channels in the same order at the same time. 2.2 Protocol Modes Figure 2-2.
WirelessUSB™ Protocol 2.2 Figure 2-3. Protocol Slave POR UnBound, KISSBind enabled UnBound, KISSBind disabled Bound Idle Mode Wait for user Bind event KISSBind Mode Bind fails Bind Mode Bridge found Reconnect Mode Search for bridge and sleep if necessary 2.2.
WirelessUSB™ Protocol 2.2 2.2.2 Idle Mode (HID only) The HID enters this mode after a power on reset before it has had any communication with the RDK bridge. If the bridge’s MID is stored in non-volatile memory the HID retrieves the bridge’s MID, calculate the network ID and move to reconnect mode. If the bridge’s MID is not stored in non-volatile memory the HID waits in idle mode until a user-initiated event causes the HID to enter bind mode.
WirelessUSB™ Protocol 2.2 2.2.5 Enhanced KISSBind™ KISSBind provides the ability to automatically bind out of the box without any intervention by the user other than installing the batteries. KISSBind essentially is a bind process while in the data mode. The bridge goes through the normal process of pinging and then going to the data mode.
WirelessUSB™ Protocol 2.2 Figure 2-4.
WirelessUSB™ Protocol 2.2 2.2.6 Unbind An ‘unbind’ mechanism allows the bridge and HIDs to return to their default unbind mode as if they had never bound to any system before. The bridge dedicates a bind flag to each device type that it supports. A bind flag is a 1-bit field in Flash. Once the bridge has been bound to an HID by either KISSBind or button bind mechanism, the bridge sets the corresponding bind flag for that device type and stores the flag in its Flash.
WirelessUSB™ Protocol 2.2 Figure 2-5.
WirelessUSB™ Protocol 2.2 2.2.9 Dynamic Data Rate and Dynamic PA Dynamic data rate and dynamic PA provide the ability to improve the immunity to interference and reduce power consumption. Dynamic data rate is device behavior based and two data modes, GFSK and 8DR, are used for the data transmission. Depending on the retry number of prior packets, the protocol determines whether to stay with the current data mode or change to another data mode.
WirelessUSB™ Protocol 2.2 2.3 Packet Structures The first byte of each packet is the Header byte. Some packets may consist only of the header byte while other packets may contain up to five bytes.
WirelessUSB™ Protocol 2.2 2.3.2 Bind Response Packet (Bridge) Byte 1 Bits: 7:4 Field: 0 3 2 2:1 Reserved Device Type 3 4 5 0 7:0 7:0 7:0 7:0 Reserved Bridge MID1 Bridge MID 2 Bridge MID 3 Bridge MID 4 Byte 1 Packet Type: 0 for bind request, 0xD for KISSBind request Device Type: This is a 2-bit field that specifies a vendor-defined device type. This allows the bridge to determine HID type.
WirelessUSB™ Protocol 2.2 2.3.5 Ping Packet (Bridge) Byte 1 Bits: 7:4 3:1 0 Field: 3 Reserved Flag Byte 1 Packet Type: 3 Flag (F): This is a 1-bit field that specifies a ping or ping response (0 = Ping, 1 = Ping Response). 2.3.6 Data Packet/Back Channel Data Packet (Bridge and HID) Data packets are sent from the HID to the bridge in connected mode. They are also sent from the bridge to the HID in connected mode if there is an asynchronous back channel. Byte 1 2 .. ..
WirelessUSB™ Protocol 2.2 2.4 Bind and Reconnect Timing When the bind button on the bridge is pressed, the bridge goes into bind mode. In bind mode, the bridge uses the bind ID to communicate with any HIDs that want to bind to the system (see section Button Bind Mode on page 17 for more information on the bind ID). The bridge enables its receiver and ‘listens’ for any bind request packets from the HID, starting from channel 0.
WirelessUSB™ Protocol 2.2 Figure 2-6. Bind Timing Diagram 4.16s x 5 Cycles ~ 21 seconds 4.16 s Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle 5 Bridge 320 ms x 13 Channels ~ 4.16 seconds 320 ms 320 ms 320 ms Channel 0 Channel 6 Channel 12 Channel 72 Channel 78 Cycle 999 Cycle 1000 Channel 72 Channel 78 23.4 ms x 1000 Cyles = 23.4 seconds 23.4 ms Cycle 1 Cycle 2 Cycle 3 Device 1.80 ms x 13 Channels = 23.4 ms 1.8 ms 1.8 ms 1.
WirelessUSB™ Protocol 2.2 Figure 2-7. Reconnect Timing Diagram Bridge Inherence detected . Move to a quieter channel in the subset Quiet channel found. Bridge will stay on this channel Keyboard = 5 seconds; Mouse = 2 seconds 430 ms Device lost connection . Search for bridge in the channel subset Reconnect Mode Device Reconnect Mode Reconnect Mode Reconnect Mode 22.88 ms x 19 Cycles ~ 430 ms 22.88 ms Cycle 1 Cycle 2 Cycle 3 Cycle 19 1.76 ms x 13 Channels = 22.88 ms 2.5 1.76 ms 1.
WirelessUSB™ Protocol 2.2 2.6 Encryption WirelessUSB PRoC LP RDK supports Tiny Encryption Algorithm (TEA) and Advanced Encryption Standard (AES) 128 to encrypt application data. Data packets may be encrypted for privacy. All encrypted data packets must have a payload of 8 or 16 bytes depending on the method chosen; this is the minimum block size for the encryption algorithm. 2.6.
WirelessUSB™ Protocol 2.2 Figure 2-8. TEA Encryption Key Management 2.6.2 AES Encryption AES_Encrypt requires the two variables tx_packet and AES_Key to be set prior to the call. Each contains a 16 byte (128 bit) value. At the completion of the function tx_packet has been encrypted inplace and contains the cipher text. AES_Key is scheduled in-place during the encryption process, so multiple calls to AES_Encrypt will each need to be proceeded with reloading of AES_Key.
WirelessUSB™ Protocol 2.2 2.6.2.1 AES Key Management The encrypt key is stored on the keyboard and the decrypt key is stored on the bridge during compiling time. There is no dynamic encrypt key exchange in the running time. 2.6.3 Encryption and Power Consumption Trade Off If the keyboard encryption is enabled, each key code is encrypted into an 8 byte key code (TEA) or 16 byte key code (AES).
WirelessUSB™ Protocol 2.
3. 3.1 Mouse Introduction This section describes the design goals, architecture, firmware source code modules and configuration options for the PRoC™ LP mouse. It does not cover the details of the radio subsystem or the configuration options that go with it. 3.1.1 Design Features The CY4672 Reference Design Kit uses a low cost PRoC LP for the RDK mouse (Cypress part number CYRF69103). Contact your local sales representative for more information.
Mouse Figure 3-1. Bottom View Bind Button and On-Off Switch Figure 3-1 shows the bottom of the mouse with the optics window, power switch, and Bind button. There are two screw holes above the label. The top of the mouse can be removed once these two screws on the bottom and one screw on the top have been extracted. Figure 3-2. Exploded Mouse View Figure 3-2 is a picture of the mouse with the top removed. The mouse consists of a single PCB that contains all of the necessary mouse components.
Mouse 3.2.2 Hardware Block Diagram Figure 3-3. Mouse Hardware Block Diagram SPI Scroll Wheel PRoC O_nCS O_ Motion Optical sensor Buttons 3.2.3 Schematics All schematics for the optical wireless mouse are located in the following directory: \Hardware\Mouse. The schematic is in Adobe Acrobat format with the letters ‘Sch’ in the file name. Figure 3-4. Printed Circuit Assembly (PDC-9347) Figure 3-4 is a picture of the controller board with the PRoC LP and optical sensor.
Mouse test mode that is compatible with the Cypress Manufacturing Test Kit, use a shorting block and short together pins 4 and 5 before power is applied. 3.2.4 Hardware Considerations The mouse design uses the SS12 schottky diode (D1) and CDH53100LC inductor (L3) for its boost circuitry. With these high efficiency components, preliminary characterization data shows a range of approximately 74-87% efficiency for the 1.8-2.7V VBAT voltage range at different temperatures (-10C to 80C).
Mouse the Device Editor showing the user module mapping. Further description of resources and user modules follow the diagram. Figure 3-5.
Mouse 3.3.2.1 Global Configuration Following is a description of the Global Resources that are configured for the CYRF69103 PRoC LP Programmable Radio on Chip. Care must be taken when modifying these values as they affect the user modules discussed below. 3.3.2.1.1 CPU Clock This parameter is set to Internal (24 MHz). In order to run the CPU at 12 MHz, CPU Clock/N needs to be set to ‘2’.
Mouse rupt API to this module is not used. See the SPI Module on page 40 for how this module is used to implement communication with multiple devices on the SPI bus. 3.3.2.3 Programmable Interval Timer User Module The Programmable Interval Timer User Module is configured to use the Internal 32-KHz Low-power Oscillator. This module is used to provide a periodic interrupt to the timer code module in order to maintain a power saving millisecond sleep routine.
Mouse The mouse firmware is partitioned into two logical groups. The Common group is a collection of code modules that provide the underlying support for the application. This group provides services such as radio protocol, radio driver, timing, polling, flash access, contact debounce, SPI, and interrupts. The Application group implements the core functionality and features of the PRoC LP RDK mouse.
Mouse In the PRoC RDK mouse design, the master SPI communicates with both the radio and optical sensor. Because the optical sensor does not supports 3-wire SPI mode, the 4-wire mode is employed. In order to save the GPIO pin, the IRQ pin function is multiplexed onto the MOSI pin. 3.3.4.4 Radio Driver The radio driver module is a low level module providing basic radio communication and configuration. Its general application is such that it is likely not to be changed by the firmware developer.
Mouse since the microcontroller sleep feature is used. Also, when polling is enabled, it is performed as a background task during the millisecond delay. This module also adjusts the tick advancement based upon the sleep resolution. Turning off the timer provides for more power savings, yet a sense of time is still preserved for non-critical timing. Note When using the ICE-Cube, define the macro PSOC_ICE so that busy waits are used instead of the sleep instruction.
Mouse which it returns to the idle state. If the mouse is unable to deliver a packet while in this state, it transitions to the disconnected state. In idle state the optical sensor is allowed to transition through its various rest modes to conserve power. In this state, the mouse application is waiting for input from the optical sensor, z-wheel or buttons. The timer is turned off to conserve power and the notion of time is maintained using the sleep timer.
Mouse observing packet data on a Listener, a correlation can be made with a USB protocol analyzer. This is useful for debugging data loss since the test mode guarantees packet delivery. Entry to this test mode can be changed by modifying the macro TESTMODE_BUTTONS in the testmode.c file. The button macros are defined in the buttons.h file. 3.3.5.4 Buttons Module The buttons module provides an API for handling both the bind and mouse buttons.
Mouse When z-wheel motion is detected, the mouse module is notified for collection and reporting of the data; see Mouse Module on page 42. 3.3.5.7 Battery Module The battery monitor circuit is implemented using the Low Voltage Interrupt (LVI) on the LP radio. Following is an explanation of the process to measure the battery voltage. The process first sets the LVI threshold to 1.8V and then checks for an LVI interrupt.
Mouse 3.3.6.5 MOUSE_CONNECT_ATTEMPT_TIMES This value sets the attempt times for the mouse trying to connect to the bridge before entering the Briefcase Mode. The default value is 20. 3.3.6.6 PLATFORM_H This configuration value identifies the header file that has the platform configuration information. The default value is pdc9347.h, which is the identifier for the mouse board that is shipped with the RDK. This macro changes when the code is ported to another platform. 3.3.6.
Mouse 3.3.6.14 KISS_BIND This configuration definition is used to selectively compile in the Enhanced KissBind feature. See Enhanced KISSBind™ on page 18 for a description of Enhanced KissBind. The mouse can be un-bound by holding the right and middle buttons, and pressing the Bind button. After being un-bound, the mouse will enter an infinite loop until a POR. After being un-bound, the mouse can be bound to a bridge by KissBind. 3.3.6.
Mouse 3.3.9.1 Packet Format 1 When there is only X, Y delta data, the transmitted packet is two bytes. Table 3-3. Packet Format 1 Byte 1 3.3.9.2 Byte 2 X Delta Y Delta (8 bits) (8 bits) Packet Format 2 When there is either z-wheel data or button data, then the transmitted packet is three bytes. In the case where there is no X, Y delta data, but there is z-wheel or button data, the X, Y delta bytes are set to zero. The z-wheel data is a signed value with bit 4 as the sign bit. Table 3-4.
Mouse The second portion is the time between the start of the ISR and the post of the event flag. For example, the motion interrupt takes 23 CPU clock cycles for this portion. Therefore, the Latency2 equals to 1.917 µs for the 12 MHz CPU. Consequently, the total latency for a motion interrupt is: Latency1 + Latency2 = 4 µs 3.3.11 Code Performance Analysis A mouse motion report is used to analyze the code performance.
Mouse 3.4.2 Tips and Tricks A couple of ways for working with the kit are the following. 3.4.2.1 M8C Sleep When using the ICE-Cube, define the macro PSOC_ICE so that busy waits are used instead of the sleep instruction. Using the sleep instruction with the ICE-Cube generates errors due to synchronization issues between the OCD part and the emulator. 3.4.2.2 Watchdog Timer The watchdog timer is enabled for the RDK operation, but may be disabled for debug purposes. 3.4.
4. 4.1 Keyboard Introduction This section covers the design goals, architecture, firmware source code modules and configuration options for the PRoC™ LP keyboard. It does not cover the details of the radio subsystem or the configuration options that go with it. 4.1.1 Design Features There are several design goals that drove the requirements for the firmware development for the keyboard. Some of these are architecture related, while others are feature related.
Keyboard 4.2.1 RDK Keyboard Assembly Figure 4-1. Keyboard Plastic Figure 4-1 shows the RDK keyboard plastic. Figure 4-2. Exploded Keyboard Figure 4-2 shows the keyboard with the top removed. The radio/enCoRe II LV board (PDC-9265) is shown in the upper right hand corner.
Keyboard Figure 4-3. Radio and PSoC Board (PDC-9265) Figure 4-3 shows the main controller board with the enCoRe II LV and WirelessUSB™ LP Radio. All of the components are on the top side of the board with the exception of the Bind button. Figure 4-4. Keyboard Battery Compartment Figure 4-4 shows the integrated battery compartment located on the bottom side of the keyboard. The battery compartment cover is also shown.
Keyboard Figure 4-5. Bind Button Figure 4-5 shows the Bind button. 4.2.2 Schematic All schematics for the PRoC LP RDK keyboard are located in the following directory: \Hardware\Keyboard. The schematic is in Adobe Acrobat format with the letters ‘Sch’ in the file name.
Keyboard 4.2.3 Keyboard Matrix The PRoC LP RDK keyboard matrix has 18 columns and 8 rows. Key presses generate a GPIO interrupt when a column is connected (shorted) to a row. The keyboard then scans the matrix to determine which keys have been pressed. The RDK keyboard matrix with the USB scan codes are shown in Table 4-1. Table 4-1.
Keyboard 4.3 Firmware Architecture There are two architectural views of the keyboard. The first is a microcontroller configuration view of user modules. This architecture and configuration is best viewed in the PSoC Designer™ application when the project is loaded. The second view is a logical organization of the source code modules that make up the keyboard application code and other support modules.
Keyboard Figure 4-6.
Keyboard 4.3.2.1 Global Configuration The following is a description of the Global Resources that are configured for the CY7C60123-PVXC enCoRe II LV microcontroller. Care must be taken when modifying these values as they affect the User Modules discussed below. CPU Clock This parameter is set to Internal (24 MHz). In order to run the CPU at 12 MHz, CPU Clock/N needs to be set to ‘2’.
Keyboard V Reset This parameter is set to 2.6V. Watchdog Enable This parameter should be set to Enable, but may be set to Disable for debug purposes. 4.3.2.2 SPI Master User Module The SPI Master User Module is used to communicate with the radio transceiver. The radio transceiver supports leading edge data latching, non-inverted clock, and MSB first transmission as defaults. A clock divisor of 6 is chosen which generates an SPI clock of 2 MHz. The interrupt API to this module is not used.
Keyboard 4.3.3 Model Figure 4-7. Firmware Architecture Model Application Common flash radio driver keyboard encryption protocol PSoC Lib tick battery timer mfgtest GPIO isr The keyboard firmware is partitioned into two logical groups. The Common group is a collection of code modules that provide the underlying support for the application. This group provides services such as, radio protocol, radio driver, timing, flash access, and interrupts.
Keyboard 4.3.4.3 Protocol Module The protocol module defines and implements the layer used to deliver packets from the device to the bridge. It manages the binding of devices to a bridge as well as the connection and interference immunity by channel hopping. This module has a dependency on the radio driver for sending and receiving formatted packets and the flash module for storing the manufacturing ID of the bridge the device is bound to. 4.3.4.
Keyboard In idle state the MCU and radio go to sleep to save power, and the keyboard application remains waiting for input from the keys or Bind button. The timer is turned off to conserve power. This state is maintained indefinitely until a keystroke or a button press occurs. The battery level is reported by the keyboard application when it detects a keystroke after it has been in an idle state for 8 seconds.
Keyboard The first test mode is initiated by holding down the left Ctrl, left Alt, right Alt, right Ctrl, and F1 keys at the same time. If PANGRAM_TEST_MODE is defined, the test sends the key up/down scan codes for the test pangram: ”a quick brown fox jumps over the lazy dog.” . Otherwise the up/down scan codes are repeatedly sent for the test sequence ‘wirelessusb’ followed by the same number of backspaces. The test repeats the appropriate sequence until the escape key is pressed.
Keyboard 4.3.6.5 KEYBOARD_TEST_MODES This configuration definition is used to selectively compile code for keyboard test modes. If this value is defined, then test modes are compiled into the executable image. If it is not defined, then the test mode code is omitted. The test modes are described in section Test Module on page 62. 4.3.6.6 KEYBOARD_TEST_MODE_PERIOD This configuration value sets the period that the keyboard generates on test key presses.
Keyboard manufacturing test code may be executed by holding the system sleep key and the Bind button when the batteries are inserted into the keyboard. 4.3.6.16 MFG_TX_MODES When the MFG_TEST_CODE is defined, the definition of this name adds in a carrier and random data TX test option. See the mfgtest module for more information on these TX modes. 4.3.6.17 MOUSE_EMULATION_MODE This configuration definition is used to selectively compile in the mouse Emulation mode.
Keyboard The keyboard scan matrix is defined in kdefs.h and may need to be changed for different keyboards. Porting the code to another microprocessor architecture requires modification or leverage of the existing code for processor specific features, along with pin definitions. 4.3.8 Initialization Initialization of the enCoRe II LV chip is done by code that is generated in boot.asm by the PSoC Designer software. The module boot.asm calls main once the enCoRe II LV has been configured and initialized.
Keyboard done to optimize the packet size based on the fact that the most common report has only one nonzero scan code without a modifier. The full Standard 101 Keys report format is shown in Table 4-5. Table 4-5. Standard 101 Keys Report Format Byte Name Scan Code 1 2 (< 0xFC) 3 Modifier Keys 4 Scan Code 2 5 Scan Code 3 6 Scan Code 4 7 Scan Code 5 8 Scan Code 6 Example The following reports is sent if a user presses an ‘a’ on the keyboard.
Keyboard 4.3.9.1.2 Multimedia Keys (Hot keys) Report An Application Report Header of 0xFF indicates that this report is a Multimedia Keys report. The Multimedia Keys report format is shown in Table 4-10. Table 4-10. Multimedia Keys Report Format Byte Name Application Report Header 2 0xFF Hot Key Scan Code 3 (upper 8 bits) Hot Key Scan Code 4 (lower 8 bits) Example The following reports is sent if a user presses the ‘Volume Increase’ (Hot Key 8) key on the keyboard.
Keyboard Example The following reports are sent if a user presses the Suspend/Sleep (Power Key 0) key on the keyboard. The Suspend/Sleep down key packet sent from the keyboard to the bridge is shown in Table 4-14. Table 4-14. Example Suspend/Sleep Down Key Power Keys Report Application Report Application Report Header Power Key Scan 0xFE 0x02 The up key packet sent from the keyboard to the bridge is shown in Example Up Key Power Keys Report. Table 4-15.
Keyboard Example of a Battery Voltage Level report with fully charged batteries is shown in Table 4-18. Table 4-18. Example ‘full’ Battery Voltage Level Report Application Report Application Battery Voltage Level Report Header 0xFD 0x0A Example of a Battery Voltage Level report with low batteries is shown in Table 4-19. Table 4-19. Example ‘low’ Battery Voltage Level Report Application Report 4.3.
Keyboard The interrupt latency includes two portions. The first portion is the time between the assertion of an enabled interrupt and the start of its ISR, which can be calculated using the following equation: Latency1 = Time for current instruction to finish + Time for M8C to change program counter to interrupt address + Time for LJMP instruction in interrupt table to execute.
Keyboard 4.4 Modifying the Keyboard Matrix or Adding New Keys The current keyboard matrix with the USB scan codes are shown in Table 4-1 on page 55. Customers may modify the keyboard matrix or they may add new keys to their keyboard. The following sections explain the procedure. 4.4.1 Modifying the Keyboard Matrix In the file kdefs.h, a table called default_keyboard_scan_table matches the keyboard matrix shown in Table 4-1 on page 55.
Keyboard 4.5 Development Environment This section informs you about the tools you may need and presents ideas you can try. 4.5.1 Tools See the CY4672 Getting Started Guide for a list of tools required to build and debug the keyboard application. Figure 4-9. RDK Keyboard with POD Installed 4.5.2 Tips and Tricks A couple of ways for working with the kit are the following. 4.5.2.1 M8C Sleep When using the ICE-Cube, define the macro PSOC_ICE so that busy waits are used instead of the sleep instruction.
Keyboard 4.5.3 Critical Test Points Figure 4-10.
5. 5.1 Bridge Introduction This section covers the design goals, architecture, firmware source code modules and configuration options for the PRoC™ LP bridge. It does not cover the details of the radio subsystem or the configuration options that go with it. 5.1.1 Design Features The CY4672 Reference Design Kit uses PRoC LP CYRF69213 for the bridge. Contact your local sales representative for more information on the PRoC LP controller.
Bridge 5.2.1 Bridge Photographs Figure 5-1 shows the top side of the RDK bridge board. The side button on the board is the Bind button. Figure 5-1. RDK Bridge Top Figure 5-2 shows the bottom side of the RDK bridge board. Figure 5-2. RDK Bridge Bottom 5.2.2 In-System Programming The PRoC LP Bridge has the capability of being programmed through the USB connector using a Cypress USB adapter board PDC-9241 as shown in Figure 5-3. Figure 5-3.
Bridge Figure 5-4 shows the PRoC LP RDK bridge connected with a USB adapter board to a PSoC MiniProg. Figure 5-4. RDK Bridge with USB Adapter and PSoC MiniProg 5.2.3 Schematics The PRoC LP RDK bridge schematics and Gerber files are located in the following directory: \Hardware\Bridge. The schematic is in Adobe Acrobat PDF format with the letters ‘Sch’ in the file name. 5.2.4 LED Usage Red LED: ■ The red LED blinks ON/OFF when the bridge is in Bind mode.
Bridge 5.3 Firmware Architecture There are two architectural views of the bridge. The first is a microcontroller configuration view of User Modules inside the controller. This architecture and configuration is best viewed in the PSoC Designer application when the project is loaded. The second view is a logical organization of the source code modules that make up the bridge application code and other support modules.
Bridge Figure 5-5.
Bridge 5.3.2.1 Global Configuration The following is a description of the Global Resources that are configured for the PRoC LP CYRF69213. Be very careful when modifying these values as they affect the User Modules discussed below. CPU Clock This parameter is set to Internal (24 MHz). In order to run the CPU at 12 MHz CPU Clock/N needs to be set to ‘2’. This operating frequency provides for faster code execution. CPU Clock / N This parameter is set to ‘2’ to provide a 12 MHz clock.
Bridge VReg This parameter is set to Disable, and the VReg will be enabled in the application code. V Keep-alive This parameter is set to Disable. Watchdog Enable This parameter should be set to Enable, but may be set to Disable for debug purposes. 5.3.2.2 SPI Master User Module The SPI Master User Module is used to communicate with the radio transceiver. The radio transceiver supports leading edge data latching, non-inverted clock, and MSB first transmission as defaults.
Bridge 5.3.3 Model Figure 5-6. Firmware Architecture Model Application Common radio driver main master protocol USB mstimer timer encrypt usb_1 flash mfgtest PSoC Lib The bridge firmware is partitioned into two logical groups. The Common group is a collection of code modules that provide the underlying support for the application. This group provides services such as, radio protocol, radio driver, USB, timing, flash access, SPI, and interrupts.
Bridge 5.3.4.1.2 USB HID Class Module (USB_1_cls_hid.asm) The additional user code provides support for the Battery Level and Link Quality software application. 5.3.4.1.3 1 Millisecond Interval Timer Interrupt Module (MSTIMER.asm) The additional user code decrements application countdown timers and checks for USB activity to detect a USB suspend condition. 5.3.4.2 Flash The module includes routines to write to the PRoC LP Flash. 5.3.4.3 Timer The module includes busy wait time routines. 5.3.4.
Bridge duration elapses with no change in report data (see the HID Specification for more information on this topic). The check_usb_idle() function also checks the timeout for down key and ‘keep alive’ packet. A ‘keep alive’ packet is transmitted every 65 ms during the time a key is pressed, so that the bridge can detect if the RF link is lost, and in that unlikely case, the bridge inserts a ‘key up’ event, to prevent a ‘stuck key’ state being transmitted to the PC.
Bridge 5.3.6 Configuration Options All configuration options for the application can be found in the config.h file, and some of them are defined in the Project > Setting > Compiler > Macro defines. Each option is explained below and can be changed to values that meet the developer’s needs. 5.3.6.1 MFG_TEST_CODE This configuration definition is used to selectively compile in the manufacturing test code.
Bridge 5.3.6.10 BACK_CHANNEL_SUPPORT This configuration definition is used to selectively compile in the Back Channel Data Support feature. See section Back Channel Data Support on page 20 for a description of Back Channel Data Support. 5.3.6.11 MASTER_PROTOCOL This configuration definition is used to select the Master radio protocol or Slave radio protocol. For the bridge application, it should be defined. 5.3.6.12 PAYLOAD_LENGTH This configuration definition is used to define the payload length.
Bridge 5.3.7 Platform and Architecture Portability The bridge firmware was designed to use the hardware features of the PRoC LP such as USB. Porting the code to another microprocessor architecture may require modification of the existing code to support the different processor specific features. 5.3.8 Initialization The initialization of the PRoC LP chip is done by code that is generated in boot.asm by the PSoC Designer software. The module boot.
Bridge 5.3.12 Code Performance Analysis A keyboard report processing is used to analyze the code performance. A typical keyboard report processing contains the following steps: ■ The bridge receives the keyboard report packet and process the packet. This step takes 108 µs. ■ MCU calls function handle_keyboard_report() to format USB packet and load this packet into the endpoint buffer. This function consumes 118 µs. As a result, it takes 226 µs for the bridge to process a keyboard report. 5.
Bridge 5.4.1.1 Device/Config Descriptors Figure 5-7. USB Device/Config Descriptors 5.4.1.2 Keyboard HID Report Descriptor The keyboard HID report descriptor defines a Boot Protocol keyboard. This enables a PRoC LP RDK keyboard with the PRoC LP RDK bridge to work on different BIOS versions that do not correctly support the USB Report Protocol. Only standard 101(104) keys are sent using this format over endpoint 1.
Bridge Figure 5-8. Keyboard HID Report Descriptor (Endpoint 1) 5.4.1.3 Mouse/Keyboard HID Report Descriptor The mouse/keyboard HID Report Descriptor uses report protocol format with a unique report ID for each report. Mouse data uses Report ID 1. The mouse report include delta x, delta y, and scroll wheel data.
Bridge Figure 5-9. Mouse HID Report Descriptor (Report ID 1 – Endpoint 2) Keyboard multimedia keys use Report ID 2. Figure 5-10.
Bridge Keyboard power keys use Report ID 3. Figure 5-11. Keyboard’s Power Keys HID Report Descriptor (Report ID 3 – Endpoint 2) Report ID 4 is used to send the mouse battery level and link quality report. Figure 5-12.
Bridge Report ID 5 is used to send the keyboard battery level and link quality report. Figure 5-13. Keyboard’s Battery/Link Quality Report Descriptor (Report ID 5–Endpoint 2) 5.4.2 Keyboard Report Format The keyboard standard keys information is sent to the host PC via the data endpoint 1. The keyboard multimedia keys and power keys information is sent to the host PC via the data endpoint 2 using Report ID (the first byte in the report). The mouse uses Report ID 1.
Bridge Figure 5-14. Keyboard Report Format Keyboard Endpoint (EP1) Right GUI Right Alt Right Shift Right Ctrl Left GUI Left Alt Left Shift Left Ctrl Reserved Standard Key 1 Standard Key 2 Standard Key 3 Standard Key 4 Standard Key 5 Standard Key 6 Figure 5-15.
Bridge 5.4.3 Mouse Report Format The mouse data is sent over the data endpoint 2 using Report ID 1. The format of the mouse report is shown below: Figure 5-16. Mouse Report Format Mouse Endpoint (EP2) Report ID 1 Middle Button Unused Right Button Left Button X Y Z Wheel 5.4.4 Battery Level and Link Quality Reports The PRoC LP bridge implements a mechanism to report the radio parameters of attached HID devices via the USB control endpoint.
Bridge The RadioParams Report is 8 bytes long and has the 6 data fields listed in Table 5-4. Table 5-4. USB Report Format Byte 5.4.4.
Bridge 5.4.5 Example USB Bus Analyzer (CATC) Traces Figure 5-17 below shows the USB data transmissions between the bridge and the host PC captured with the USB CATC Bus Analyzer. In this example, the Right Shift + ‘g’, ‘h’ keys were typed followed by the ‘Volume Up’, ‘Volume Down’ keys. Note the keyboard regular key reports are sent to the PC via the endpoint 1 while the Multimedia key reports are sent via the endpoint 2 with Report ID 2. Figure 5-17.
Bridge Figure 5-18 below shows the mouse data being transferred between the bridge and the host PC. The first part of the trace shows the mouse data when the left button was pressed and held down as the mouse was moved, and then the left button was released. The second part of the trace shows the Z-wheel being moved down and up. Figure 5-18.
Bridge Figure 5-19 shows the Sleep key being pressed. Note the power key reports are sent via endpoint 2 and Report ID 3. Figure 5-19. Example Keyboard CATC Trace (Power Key) Report ID 3 = Power Key Key Code Key Up Figure 5-20 below shows the Get_Report requests used to retrieve the keyboard and mouse battery level and link quality information. Note the data transfers occurred on the control endpoint, endpoint 0, and Report ID were used to differentiate keyboard and mouse requests. Figure 5-20.
Bridge 5.5 Development and Debug Environment Information on the tools required and tips on using those tools are presented in this section. 5.5.1 Tools See the CY4672 Getting Started Guide for a list of tools required to build and debug the bridge application. Figure 5-21. RDK Bridge with POD Installed 5.5.2 Tips and Tricks A few of ways for working with the kit are the following.
6. 6.1 Manufacturing Test Support, MTK Introduction The Manufacturing Test Kit (MTK) provides production line test support in addition to providing FCC certification tests. This section provides a description of the Tester serial protocol, the RF protocol between the MTK Tester and the MTK Device-Under-Test (DUT) and a brief description of porting the MTK DUT code to different platforms. Refer to the Manufacturing Test Kit User’s Guide for instructions on operating the MTK Tester. 6.
Manufacturing Test Support, MTK Table 6-1.
Manufacturing Test Support, MTK Table 6-3. Serial Port Parameter Settings 6.4 Serial Port Parameter Setting Baud Rate 9600 Parity None Number of Data Bits 8 Number of Stop Bits 1 MTK RF Protocol Command packets received by the Device-Under-Test (DUT) are ‘echoed’ with the addition of an added byte that contains the count of invalid bits for the received packet. Extra bytes in packets that are larger than what the DUT can support are ignored.
Manufacturing Test Support, MTK 104 CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
7. 7.1 Regulatory Testing Results Introduction The PRoC™ LP RDK leverages the regulatory work done for the CY4636 RDK. The CY4636 LP mouse was tested in a certified lab and meets FCC part 15, Subpart B, Title 47 CFR–Unintentional radiators, FCC Part 15 Subpart C–Intentional radiators, and Industry Canada RSS-Gen. The following table outlines the results of the testing. Testing for the keyboard and bridge is expected in the near future. Table 7-1.
Regulatory Testing Results 106 CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
8. Power Considerations 8.1 RDK Keyboard 8.1.1 Usage Model The following usage model are considered for the RDK keyboard. 8.1.2 ■ 4 hours per day of 6 keystrokes per second, 5 days per week. ■ 24 hours per day with no activity, 2 days per week. ■ A packet is transmitted on both key-up and key-down events. ■ A ‘keep alive’ is transmitted for each key-down event.
Power Considerations 8.1.3 Battery Life Calculations The following table shows the times spent in each state by the RDK keyboard usage model. By substituting the current measurements in section Current Measurements on page 107, the overall average Icc for RDK keyboard can be calculated. Table 8-2. Mouse Current Measurement Mode Week day Weekend Hrs/day Days Average Icc (mA) Active 4 5 0.89 Charge (mAh) 17.8 Idle 20 5 0.04 4 Idle 24 2 0.04 1.92 Charge Per Week (mAh) 23.
Power Considerations 8.2.2 Current Measurements The following is the results of RDK mouse current measurement: Table 8-3. RDK keyboard Power Consumption 8.2.3 Operation Mode Icc (mA) with Supply Voltage = 2.5V Icc (mA) with Supply Voltage = 2.8V Average Icc (mA) Active mode–Move the mouse in a circle on white paper. 8 6.9 7.5 Rest1 mode–Allow the mouse to sit idle for 1 second after being in the active state. 2.03 1.81 1.
Power Considerations 110 CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
9. 9.1 Software Guide Introduction This section describes the software source code modules used in order to communicate with the PRoC™ LP bridge HID device to obtain the current radio parameters for the attached WirelessUSB™ LP devices. It does not cover the details of the Microsoft Foundation Class (MFC) Library or the HID Library that contains standard system-supplied routines that user-mode applications use to communicate with USB devices that comply with the USB HID Standard.
Software Guide 9.2.1.1 CHidDevice Class Methods Table 9-1. CHidDeviceClass Methods Method 112 Type Description OpenHidDevice() Public This method sets appropriate access rights, attempts to open a handle to the HID device, obtains the top collection data, and makes a call to setup input, output, and feature data buffers. CloseHidDevice() Public This method closes the HID device handle, un-registers the HID device notification, and frees pre-parsed data and data/report buffers.
Software Guide 9.2.1.2 CHidManager Class Methods Table 9-2. CHidManagerClass Methods Method Type Description Create() Public This method creates an invisible window and uses the returned window handle to register for HID device notification events, then it creates a list of existing HID devices that will be maintained by the HID manager. IsHidDevicePresent() Public This method attempts to open a handle to the HID device to determine if it is present (or not) and returns the result.
Software Guide 9.2.2 System Tray Module The System Tray module defines the CCySysTray class which provides the interface to the system tray for the application. This module is not expected to require any modification, however all source code is provided for reference. 9.2.2.1 CCySysTray Class Methods Table 9-3. CCySysTray Methods Method 114 Type Description Create() Public This method creates an invisible window and sets up the system tray icon (if needed).
Software Guide 9.2.3 WirelessUSB System Tray Application Module The WirelessUSB System Tray module is the main system tray application. This module places the icon on the system tray bar, manages the HID devices, displays pop up messages, and controls the WirelessUSB Status Property Sheet. Additionally, via command-line parameters, this module can enable and disable the system tray application from running at startup. 9.2.3.
Software Guide 9.2.3.2 CMainFrame Class Methods The CMainFrame class is the Visual C++ generated file that is a derived frame-window class for the system tray application's main frame window. This class has been modified to also perform the timer based polling of the PRoC LP bridge HID device to obtain the radio parameters and display any appropriate pop up messages. Additionally, this class also processes the command message to create the WirelessUSB Status Property Sheet. Table 9-5.
Software Guide 9.2.3.3 CWirelessUSBStatusPropertyPage Class Methods The CWirelessUSBStatusPropertyPage class is the Visual C++ generated file that implements the WirelessUSB Device Status Property Page, a unique property page is created for each WirelessUSB device enumerated. Table 9-6.
Software Guide 9.2.3.5 CHidTrayDevice Class Methods The CHidTrayDevice class is derived from the CHidDevice class and is the class used to interface with WirelessUSB devices. Table 9-8. CHidTrayDevice Methods Method 9.2.3.6 Type Description RequestNewUsageValues() Public This method sets up and issues a Set Feature request to the HID device, which now simply requests the wireless device to provide an update of its battery level the next time it communicates with the USB bridge.
Appendix A. References CY4672 Getting Started PSoC Designer™ version 4.3 documentation CY3631 Manufacturing Test Kit Device Class Definition for Human Interface Devices (HID) (http://www.usb.org/developers/hidpage) Avago ADNS-3040 Low Power Optical mouse Sensor Data Sheet CYRF69103/213 PRoC™ LP Data Sheet CYRF6936 WirelessUSB™ LP 2.
CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
Index Numerics button bind mode 17 1 millisecond interval timer user module 81 A acronyms 10 advanced encryption standard 29 decrypt key 31 encrypt key 31 AES See advanced encryption standard AES encryption 30 application code 83 architecture keyboard 51 AutoACK 14, 27 automatic acknowledgment 14 B back channel data support 20 transaction sequence 21 base channel 14 battery life calculations keyboard 108 mouse 109 battery quality report descriptor 93 battery reading 96 bind and reconnect timing 26 bind
Index firmware architecture model 82 flash security 81 M H hardware bridge overview 75 keyboard overview 51 mouse overview 33 RDK keyboard assembly 52 HID See human interface devices human interface devices 13 I idle mode HID only 17 initialization of the PRoC LP chip 87 K keyboard application code 61 architecture 51 code performance 71 common code 60 configuration options 51 critical test points 74 development environment 73 enCoRe II device configuration 56 firmware architecture 56 firmware architect
Index connect request 24 connect response packet (bridge) 24 ping packet (bridge) 25 ping mode bridge only 16 platform and architecture portability 87 PN code See pseudo noise codes power considerations RDK keyboard 107 RDK mouse 108 PRoC LP bridge architecture 75 PRoC LP keyboard 51 protocol MTK RF 103 serial command 102 serial response 102 protocol modes master 15 slave 16 pseudo noise codes 13, 14 PSoC Designer generated files MSTIMER.asm 83 USB_1.inc 82 USB_1_cls_hid.
Index 124 CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
Revision History Document Revision History Document Title: CY4672 Reference Design Kit Guide Document Number: Revision ECN# Issue Date Origin of Change Description of Change 1.0 10/3/06 ARI New document. The Beta copy of this manual was in Word. Converted to Framemaker template, added new material. 1.1 12/19/06 ARI Replaced figures 3-5, 4-6, 5-4, 5-5, 5-8, and 5-21. Replace tables 8-1, 8-2, 8-3, and 8-4.Made other edits per NDX 1.2 01/02/07 ARI Added Figure 3.
CY4672 Reference Design Guide, Document # 001-16968 Revision ** [+] Feedback
