WirelessUSB LP_PRoC LP TRM.pdf

WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar
Technical Reference Manual
Document # 001-12603 Rev. *J
September 10, 2015
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone (USA): 800.858.1810
Phone (Intnl): 408.943.2600
http://www.cypress.com
Copyrights
Copyrights
© Cypress Semiconductor Corporation, 2007-2015. 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. 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 reasonably be expected to result in significant injury to the user.
The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such
use and in doing so indemnifies Cypress against all charges.
Cypress, the Cypress Logo, WirelessUSB, WirelessUSB LS, WirelessUSB LR, PRoC, enCoRe, and PSoC Designer are
trademarks or registered trademarks of Cypress Semiconductor. Windows is a registered trademark of Microsoft Corporation.
All other trademarks or registered trademarks referenced herein are property of the respective corporations.
Purchase of I2C components from Cypress or one of its sublicensed Associated Companies conveys a license under the Philips I2C Patent Rights to use these components in an I2C system, provided that the system conforms to the I2C Standard
Specification as defined by Philips.
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-transferable 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 applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified 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 significant injury to the 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.
2
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Contents
Section A: Overview
9
Getting Started ...................................................................................................................................9
Cypress Semiconductor Support ..............................................................................................9
Third-Party Support ...................................................................................................................9
Document History .............................................................................................................................10
Document Conventions ....................................................................................................................11
Register Conventions ..............................................................................................................11
Numeric Naming .....................................................................................................................11
Units of Measure .....................................................................................................................11
Acronyms ................................................................................................................................11
1. Introducing WirelessUSB™ LP/LPstar
1.1
1.2
1.3
1.4
1.5
1.6
1.7
2. Design Considerations
2.1
2.2
2.3
2.4
13
Introduction .............................................................................................................................13
Introduction to Wireless ..........................................................................................................13
1.2.1 The Medium ................................................................................................................14
1.2.2 Moving Data ................................................................................................................14
1.2.3 Structure of Data .........................................................................................................15
1.2.4 Protocol .......................................................................................................................15
Simple Network Parameters ...................................................................................................15
1.3.1 Channel.......................................................................................................................15
1.3.2 PN Code......................................................................................................................16
1.3.3 Other Parameters........................................................................................................16
WirelessUSB LP/LPstar Features Summary ..........................................................................17
1.4.1 Backward Compatibility...............................................................................................17
1.4.1.1 DDR Mode...................................................................................................18
1.4.1.2 SDR Mode ...................................................................................................18
PRoC LP/LPstar Features Summary......................................................................................19
Block Diagrams.......................................................................................................................20
1.6.1 WirelessUSB LP/LPstar ..............................................................................................20
1.6.2 PRoC LP .....................................................................................................................20
Device Options ......................................................................................................................22
23
Introduction .............................................................................................................................23
Power......................................................................................................................................23
2.2.1 Power Source..............................................................................................................23
2.2.1.1 ‘Unlimited’ Power Supplies ..........................................................................23
2.2.1.2 Battery Powered Devices ............................................................................24
2.2.2 Peak and Average Current..........................................................................................24
2.2.3 Voltage Range.............................................................................................................24
Range .....................................................................................................................................24
Throughput .............................................................................................................................25
2.4.1 Data Rate ....................................................................................................................25
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
3
Contents
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.4.2 Payload Frequency (Report Rate) .............................................................................. 25
2.4.3 Payload Size ............................................................................................................... 25
Latency ................................................................................................................................... 26
Link Architecture..................................................................................................................... 26
2.6.1 Topology ..................................................................................................................... 26
2.6.2 Number of Devices ..................................................................................................... 26
2.6.3 Direction...................................................................................................................... 27
Interference Avoidance...........................................................................................................27
Co-Location ............................................................................................................................ 28
Transfer Type ......................................................................................................................... 28
Binding.................................................................................................................................... 28
Footprint ................................................................................................................................. 29
Cost ........................................................................................................................................ 29
Time-to-Market ....................................................................................................................... 29
Manufacturability .................................................................................................................... 29
Testing.................................................................................................................................... 29
2.15.1 System Quality Assurance.......................................................................................... 29
2.15.2 Regulatory .................................................................................................................. 30
2.15.3 Manufacturing ............................................................................................................. 30
3. Resets
3.1
3.2
3.3
3.4
3.5
31
Introduction............................................................................................................................. 31
Power On Reset ..................................................................................................................... 31
3.2.1 POR via Capacitor ...................................................................................................... 31
3.2.2 POR via Microcontroller ..............................................................................................33
Hard Reset ............................................................................................................................. 34
Soft Reset............................................................................................................................... 35
POR Event Power Cycling...................................................................................................... 35
4. Interrupts
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4
37
Introduction............................................................................................................................. 37
Physical Layer ........................................................................................................................ 37
IRQ During POR..................................................................................................................... 38
Transmit IRQs ........................................................................................................................ 38
Receiver IRQs ........................................................................................................................ 38
Debouncing Non-Atomic Radio Status Bits ............................................................................ 39
IRQ Events ............................................................................................................................. 40
4.7.1 Successful Transactions ............................................................................................. 40
4.7.2 Unsuccessful Transaction: Out of Range ................................................................... 42
4.7.3 Unsuccessful Transaction: Buffer Error Due to Transmitting > 16 Bytes .................... 43
4.7.4 Unsuccessful Read: Buffer Error - Reading From an Empty RX Buffer...................... 45
IRQ Sources ........................................................................................................................... 46
4.8.1 Transmit ...................................................................................................................... 46
4.8.1.1 TXE ............................................................................................................. 46
4.8.1.2 TXC ............................................................................................................. 46
4.8.1.3 TXBERR...................................................................................................... 46
4.8.1.4 TXB0 ...........................................................................................................46
4.8.1.5 TXB8 ...........................................................................................................46
4.8.1.6 TXB15 ......................................................................................................... 46
4.8.1.7 TX CLR........................................................................................................ 46
4.8.1.8 TX GO ......................................................................................................... 46
4.8.2 Receive ....................................................................................................................... 46
4.8.2.1 RXE ............................................................................................................. 46
4.8.2.2 RXC............................................................................................................. 46
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Contents
4.8.2.3 RXBERR......................................................................................................46
4.8.2.4 RXB1 ...........................................................................................................46
4.8.2.5 RXB8 ...........................................................................................................46
4.8.2.6 RXB16 .........................................................................................................46
4.8.2.7 RX GO .........................................................................................................46
4.8.2.8 RXOW .........................................................................................................46
4.8.3 Power ..........................................................................................................................46
4.8.3.1 LVI(For WirelessUSB LP and PRoC LP only) .............................................46
4.8.4 Oscillator .....................................................................................................................46
4.8.4.1 Stable ..........................................................................................................46
4.9 Status......................................................................................................................................46
4.9.1 Transmit ......................................................................................................................46
4.9.2 Receive .......................................................................................................................46
4.9.2.1 SOPDET......................................................................................................46
4.9.2.2
RXB1 ..........................................................................................................46
4.10 Muxing IRQ Signal onto MOSI................................................................................................46
5. Crystal
5.1
5.2
5.3
5.4
47
Introduction .............................................................................................................................47
Guidelines...............................................................................................................................47
5.2.1 Clock ...........................................................................................................................47
5.2.1.1 Clock Requirements ....................................................................................47
5.2.1.2 Clock Frequency..........................................................................................47
5.2.1.3 Clock Accuracy............................................................................................47
5.2.2 PPM ............................................................................................................................48
5.2.2.1 Base PPM....................................................................................................48
5.2.2.2 Temperature PPM .......................................................................................48
5.2.2.3 Aging PPM...................................................................................................48
5.2.3 Load Capacitance .......................................................................................................48
5.2.4 Pullability and Trim Sensitivity.....................................................................................48
5.2.5 Crystal Choice Considerations....................................................................................48
5.2.6 Clock Frequency Measurements ................................................................................48
5.2.7 Crystal Layout .............................................................................................................48
Typical Usage .........................................................................................................................49
5.3.1 Startup.........................................................................................................................50
5.3.1.1 Cold Start (Power On Reset).......................................................................50
5.3.1.2 Warm Start (Sleep/Wake)............................................................................50
Notes ......................................................................................................................................50
6. Power Management Unit
6.1
6.2
6.3
51
Introduction .............................................................................................................................51
6.1.1 Functional Description.................................................................................................51
6.1.2 Power Supply Choices ................................................................................................53
6.1.2.1 Battery Configuration...................................................................................54
6.1.3 Fixed Value Inductor and Capacitor ............................................................................55
6.1.3.1 Selecting a Suitable Inductor.......................................................................55
6.1.3.2 Low-Noise LDO Linear Regulator Configuration .........................................55
6.1.4 Filtering Power Supply Noise ......................................................................................56
6.1.5 Switching Regulator Frequency ..................................................................................56
Sleep Mode.............................................................................................................................57
6.2.1 Wake from Sleep Response Time...............................................................................57
LVI IRQ ...................................................................................................................................57
6.3.1 Implementing Low Voltage Monitoring ........................................................................57
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
5
Contents
7. Digital Baseband
7.1
7.2
7.3
7.4
59
Introduction............................................................................................................................. 59
Modem.................................................................................................................................... 60
7.2.1 Gaussian Frequency Shift Key ................................................................................... 60
7.2.2 Eight x Data Rate........................................................................................................ 60
7.2.3 Double Data Rate ....................................................................................................... 61
7.2.4 Single Data Rate......................................................................................................... 61
Backward Compatibility .......................................................................................................... 61
Framer .................................................................................................................................... 63
7.4.1 Packet Structure ......................................................................................................... 63
7.4.1.1 Preamble ..................................................................................................... 63
7.4.1.2 Start of Packet............................................................................................. 63
7.4.1.3 Data............................................................................................................. 65
7.4.1.4 Length ......................................................................................................... 65
7.4.1.5 Cyclic Redundancy Check .......................................................................... 65
7.4.2 ACK Packets...............................................................................................................66
7.4.3 End of Packet Detection ............................................................................................. 66
8. Radio Initialization and Operation
8.1
8.2
8.3
8.4
8.5
6
67
Introduction............................................................................................................................. 67
Usage ..................................................................................................................................... 67
8.2.1 Initialization ................................................................................................................. 67
8.2.2 Transmitting ................................................................................................................ 68
8.2.3 Receiving .................................................................................................................... 68
Requirements ......................................................................................................................... 68
8.3.1 Header Files ............................................................................................................... 68
8.3.2 Hardware Interface ..................................................................................................... 68
8.3.3 Pins............................................................................................................................. 68
Type Declarations................................................................................................................... 69
Radio High Level Functions.................................................................................................... 70
8.5.1 RadioInit...................................................................................................................... 70
8.5.2 RadioSetChannel........................................................................................................ 71
8.5.3 RadioSetFrequency .................................................................................................... 71
8.5.4 RadioGetChannel ....................................................................................................... 72
8.5.5 RadioGetFrequency.................................................................................................... 72
8.5.6 RadioSetTxConfig....................................................................................................... 73
8.5.7 RadioGetTxConfig ...................................................................................................... 73
8.5.8 RadioSetXactConfig ................................................................................................... 74
8.5.9 RadioGetXactConfig ................................................................................................... 74
8.5.10 RadioSetFrameConfig ................................................................................................ 75
8.5.11 RadioGetFrameConfig ................................................................................................ 75
8.5.12 RadioSetThreshold32 ................................................................................................. 76
8.5.13 RadioGetThreshold32................................................................................................. 76
8.5.14 RadioSetThreshold64 ................................................................................................. 77
8.5.15 RadioGetThreshold64................................................................................................. 77
8.5.16 RadioSetPreambleCount ............................................................................................ 78
8.5.17 RadioGetPreambleCount............................................................................................ 78
8.5.18 RadioSetPreamblePattern .......................................................................................... 79
8.5.19 RadioGetPreamblePattern.......................................................................................... 79
8.5.20 RadioSetCrcSeed ....................................................................................................... 80
8.5.21 RadioGetCrcSeed....................................................................................................... 80
8.5.22 RadioGetFuses ...........................................................................................................81
8.5.23 RadioGetRssi.............................................................................................................. 81
8.5.24 RadioSetConstSopPnCode ........................................................................................ 82
8.5.25 RadioSetConstDataPnCode ....................................................................................... 82
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Contents
8.6
8.5.26 RadioSetSopPnCode ..................................................................................................83
8.5.27 RadioStartTransmit .....................................................................................................83
8.5.28 RadioGetTransmitState ...............................................................................................84
8.5.29 RadioEndTransmit ......................................................................................................84
8.5.30 RadioAbort ..................................................................................................................85
8.5.31 RadioBlockingTransmit ...............................................................................................86
8.5.32 RadioStartReceive ......................................................................................................87
8.5.33 RadioGetReceiveState................................................................................................88
8.5.34 RadioEndReceive .......................................................................................................89
8.5.35 RadioGetReceiveStatus ..............................................................................................89
8.5.36 RadioInterrupt .............................................................................................................90
8.5.37 RadioPoll.....................................................................................................................91
8.5.38 RadioState...................................................................................................................92
Radio SPI Access Routines....................................................................................................93
8.6.1 RadioReset .................................................................................................................93
8.6.2 RadioRead ..................................................................................................................93
8.6.3 RadioWrite ..................................................................................................................94
8.6.4 RadioSetPtr.................................................................................................................94
8.6.5 RadioSetLength ..........................................................................................................95
8.6.6 RadioBurstWrite ..........................................................................................................95
8.6.7 RadioFileWrite.............................................................................................................96
8.6.8 RadioBurstRead..........................................................................................................96
8.6.9 RadioFileRead ............................................................................................................97
9. Managing Power
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
99
Introduction .............................................................................................................................99
Power Advantages of DSSS...................................................................................................99
General Principles ................................................................................................................100
WirelessUSB Power Saving Modes......................................................................................100
Two-Way System Overview..................................................................................................100
Data Transmission Process..................................................................................................101
Timing Considerations ..........................................................................................................101
Wakeup Timing.....................................................................................................................102
Synthesizer Start Timing.......................................................................................................102
Preamble Timing...................................................................................................................102
Transmit and Receive Mode Timing .....................................................................................102
Debugging Tips.....................................................................................................................102
10. Registers
103
10.1 Introduction ...........................................................................................................................103
10.1.1 Example Register Formats........................................................................................103
10.1.2 Other Conventions ....................................................................................................103
10.2 Maneuvering Around the Registers ......................................................................................104
10.2.1 Accessing Registers..................................................................................................104
10.3 Register Conventions ...........................................................................................................104
10.4 Register Descriptions............................................................................................................105
10.5 Register Details and Examples.............................................................................................106
10.5.1
CHANNEL_ADR ..................................................................................................106
10.5.2
TX_LENGTH_ADR ..............................................................................................107
10.5.3
TX_CTRL_ADR ....................................................................................................108
10.5.4
TX_CFG_ADR .....................................................................................................109
10.5.5
TX_IRQ_STATUS_ADR ......................................................................................110
10.5.6
RX_CTRL_ADR ...................................................................................................112
10.5.7
RX_CFG_ADR .....................................................................................................113
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
7
Contents
10.5.8
10.5.9
10.5.10
10.5.11
10.5.12
10.5.13
10.5.14
10.5.15
10.5.16
10.5.17
10.5.18
10.5.19
10.5.20
10.5.21
10.5.22
10.5.23
10.5.24
10.5.25
10.5.26
10.5.27
10.5.28
10.5.29
10.5.30
10.5.31
10.5.32
10.5.33
10.5.34
10.5.35
10.5.36
10.5.37
10.5.38
10.5.39
10.5.40
10.5.41
10.5.42
10.5.43
10.5.44
10.5.45
Index
8
RX_IRQ_STATUS_ADR ......................................................................................114
RX_STATUS_ADR ..............................................................................................116
RX_COUNT_ADR ................................................................................................117
RX_LENGTH_ADR ..............................................................................................118
PWR_CTRL_ADR ................................................................................................119
XTAL_CTRL_ADR ...............................................................................................120
IO_CFG_ADR ......................................................................................................121
GPIO_CTRL_ADR ...............................................................................................122
XACT_CFG_ADR ...............................................................................................123
FRAMING_CFG_ADR ........................................................................................124
DATA32_THOLD_ADR .......................................................................................125
DATA64_THOLD_ADR .......................................................................................126
RSSI_ADR ..........................................................................................................127
EOP_CTRL_ADR ...............................................................................................128
CRC_SEED_LSB_ADR ......................................................................................129
CRC_SEED_MSB_ADR .....................................................................................130
TX_CRC_LSB_ADR ...........................................................................................131
TX_CRC_MSB_ADR ..........................................................................................132
RX_CRC_LSB_ADR ...........................................................................................133
RX_CRC_MSB_ADR ..........................................................................................134
TX_OFFSET_LSB_ADR .....................................................................................135
TX_OFFSET_MSB_ADR ....................................................................................136
MODE_OVERRIDE_ADR ...................................................................................137
RX_OVERRIDE_ADR .........................................................................................138
TX_OVERRIDE_ADR .........................................................................................139
XTAL_CFG_ADR ................................................................................................140
CLK_OFFSET_ADR ...........................................................................................141
CLK_EN_ADR ....................................................................................................142
RX_ABORT_ADR ...............................................................................................143
AUTO_CAL_TIME_ADR .....................................................................................144
AUTO_CAL_OFFSET_ADR ...............................................................................145
ANALOG_CTRL_ADR ........................................................................................146
TX_BUFFER_ADR .............................................................................................147
RX_BUFFER_ADR .............................................................................................148
SOP_CODE_ADR ..............................................................................................149
DATA_CODE_ADR ............................................................................................150
PREAMBLE_ADR ...............................................................................................151
MFG_ID_ADR .....................................................................................................152
153
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Section A: Overview
This section lists the abbreviations and acronyms that Cypress uses in its product documentation.
Getting Started
The quickest path to understanding the WirelessUSBTM LP/LPstar and PRoCTM LP/LPstar is by reading the device’s data
sheet and application notes. This manual is useful for understanding the details of both the WirelessUSB LP/LPstar and the
Low Power Programmable Radio System on a Chip–PRoC LP/LPstar (ICs).
Important Note For the most up-to-date ordering, packaging, or electrical specification information, refer to the individual
device’s data sheet or go to http://www.cypress.com.
Cypress Semiconductor Support
Technical Support can be reached at http://www.cypress.com/support or can be contacted by phone at: 1-800-541-4736.
The following related documentation can be found on the Cypress web site.
Document Number
Document Type
Document Name
38-16015
Data Sheet
CYRF6936 WirelessUSB LP 2.4GHz Radio SoC
001-07552
Data Sheet
CYRF69213 Programmable Radio on Chip-LP
001-07611
Data Sheet
CYRF69103 Programmable Radio on Chip–Low Power
001-66073
Data Sheet
CYRF6986 WirelessUSB LPstar 2.4GHz Radio SoC
001-66502
Data Sheet
CYRF69303 Programmable Radio on Chip Low Power
001-66503
Data Sheet
CYRF69313 Programmable Radio on Chip Low Power
AN4002
Application Note
Calculating Battery Life in WirelessUSBTM Systems
AN4003
Application Note
WirelessUSBTM 2-Way HID Systems
AN4004
Application Note
Interference Mitigation Challenges and Solutions in the 2.4 to 2.5 GHz ISM
Band
AN6066
Application Note
Wireless Binding Methodologies
AN17581
Application Note
WirelessUSBTM LP/LPstar RDK Japanese Radio Law Testing and Verification
AN48610
Application Note
Design and Layout Guidelines for Matching Network and Antenna for WirelessUSBTM LP/LPstar
AN68105
Application Note
Migration of WirelessUSB™ LP Designs to WirelessUSB™ LPstar
Third-Party Support
There are two established providers of Cypress RF modules, Artaflex Inc. and Unigen Corp. These vendors can provide
assembled and tested modules that are already EMC tested and approved for the various worldwide markets.
Cypress Semiconductor products are available from various worldwide distributors who can may also offer individual design
assistance.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
9
Document History
This section serves as a chronicle of the WirelessUSBTM LP/LPstar and PRoCTM LP/LPstar Technical Reference Manual.
WirelessUSBTM LP/LPstar and PRoCTM LP/LPstar Technical Reference Manual History
Release Date
10
Version
Originator
Description of Change
01/10/2007
**
ARI
This manual is a new document to the Cypress Document Control (Revision **) system; this manual has gone
through several versions as an internal document. The manual itself is labeled Version 0.71 but is in fact the
same as Version **. This document has been issued the document number 001-12603.
03/31/2007
*A
ARI
Added a Document History section. Added the Resets chapter.
06/28/2007
*B
ARI
Renamed the Power Management chapter to Managing Power. Added the Power Management Unit chapter.
09/19/2007
*C
ARI
Converted manual to two-column format.
Add Interrupts chapter. Update Introducing WirelessUSB™ LP chapter. Add Backward Compatibility. Update
Crystal chapter. Update Registers chapter. Update pinout, reset, and crystal figures.
04/25/2008
*D
HMT
11/08/2010
*E
HEMP
Overview: Expand the App. Notes list. Add 3rd party section. Add abbreviation.
Chap. 1: update 1.2.1. Fix p/n in Table 1-3. Change molded part number to the saw-cut part number.
Chap. 3: 3.2.1: correct Kemet p/n and add note about capacitor reliability.
Chap. 6: 6.1.3.1: Add additional detail about inductor saturation.
Add LPstar to this TRM to make it compatible with LP/LPstar
05/05/2011
*F
KKCN
08/01/2011
*G
KPMD
12/04/2013
*H
LIP
Sunset review
12/03/2014
*I
LIP
Deleted section 1.8 - Packages
09/10/2015
*J
LIP
Added PRoC LPStar devices with 'LTXC' package in Table 1-3.
Changed posting to external web.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Document Conventions
This manual uses the Courier New font to distinguish code examples from regular text. File names are presented in italics
text.
Register Conventions
The register conventions that are specific to this manual are described in Registers chapter on page 103.
Numeric Naming
Hexidecimal numbers are represented with all letters in uppercase with an appended lowercase ‘h’ (for example, ‘14h’ or
‘3Ah’) and hexidecimal numbers may also be represented by a ‘0x’ prefix, the C coding convention. Binary numbers have an
appended lowercase ‘b’ (for example, 01010100b’ or ‘01000011b’). Numbers not indicated by an ‘h’ or ‘b’ are decimal.
Units of Measure
Acronyms
The following table lists the units of measurements that are
used in this manual.
The following table lists the acronyms that are used in this
manual.
Units of Measurement
Acronyms
Symbol
Unit of Measure
Acronym
Description
oC
degree Celsius
8DR
eight x data rate
dB
decibels
AC
alternating current
ACK
acknowledge
analog-to-digital converter
GHz
Hz
giga hertz
hertz
k
kilo, 1000
ADC
K
210, 1024
API
application programming interface
KB
1024 bytes
ATS
auto transaction sequencer
Kbit
1024 bits
BER
bit error rate
Kbps
kilobits per second
kHz
kilohertz (32.000)
BOM
bill-of-materials
k
kilohm
BR
bit rate
Mbps
megabits per second
CMRR
common mode rejection ratio
MHz
megahertz
CPU
central processing unit
M
megaohm
A
microampere
CRC
cyclic redundancy check
F
microfarad
DC
direct current
H
microhenry
DDR
double data rate
s
microsecond
DMA
direct memory access
mA
milli-ampere
ms
milli-second
DSSS
direct sequence spread spectrum
mV
milli-volts
EEPROM
nA
nanoampere
electrically erasable programmable read only memory
ns
nanosecond
EFTB
electrostatic fast transient burst

ohm
EMC
electromagnetic compatability
pF
picofarad
EMI
electromagnetic interference
EOP
end of packet
ESD
electro-static discharge
FEC
forward error correction
FCC
federal communications commission
FHSS
frequency hopping spread spectrum
FIFO
first in first out
FSK
frequency-shift keying
GFSK
Gaussian frequency shift key
GPIO
general purpose IO
ppm
parts per million
sps
samples per second
V
volts
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
11
Acronyms (continued)
Acronym
Description
HID
human interface device
ICE
in-circuit emulator
IDE
Integrated Development Environment
ILO
internal low speed oscillator
IMO
internal main oscillator
IO
input/output
IRQ
interrupt request
ISM
industrial, scientific and medical
ISR
interrupt service routine
ISSP
in system serial programming
LDO
low drop-out
LPF
low pass filter
LSb
least significant bit
LSB
least significant byte
LVD
low voltage detect
Mbps
megabits per second
MISO
master-in-slave-out
MOSI
master-out-slave-in
MSb
most significant bit
MSB
most significant byte
PER
packet error rate
PCB
printed circuit board
PMU
power management unit
PN
pseudo noise
POR
power on reset
RAM
random access memory
RF
radio frequency
RSSI
receive signal strength indication
RST pin
reset pin
RW
read/write
SDR
single data rate
SIE
serial interface engine
SNR
signal-to-noise ratio
SOF
start of frame
SOP
start of packet
SPI
serial peripheral interface
SPIM
serial peripheral interconnect master
SPIS
serial peripheral interconnect slave
SRAM
static random access memory
USB
universal serial bus
VCO
voltage controlled oscillator
12
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
1. Introducing WirelessUSB™ LP/LPstar
1.1
Introduction
Welcome to Cypress WirelessUSBTM and PRoCTM –
Programmable Radio System-on-Chip. Cypress is now on
its second generation of wireless technology, which is the
focus of this manual. The first generation products included
WirelessUSB LSTM, WirelessUSB LRTM, and the original
PRoC device. Although there were different features and
capabilities in these devices, they all fundamentally used the
same radio and baseband technology.
In the same way, Cypress developed a new generation
wireless technology to leverage among several devices.
Because of the common underlying intellectual property
these devices possess, they are discussed together with
only minor diversions to highlight differences in capability.
Therefore, the scope of this manual includes the following
Cypress products:
■
WirelessUSB LP
❐
■
■
One additional note about the PRoC LP/LPstar devices:
PRoC LP/LPstar is the marriage of IP from the WirelessUSB
LP/LPstar radio with the microcontroller IP from the Cypress
enCoReTM II and Wireless enCoRe II devices. The data
sheets for the PRoC LP/LPstar devices include a substantial
amount of information about the microcontrollers, see
Cypress Semiconductor Support on page 9. Furthermore,
the PSoC DesignerTM tool set, which is used for enCoRe II
development, includes examples and firmware IP to jump
start development with the features of the microcontrollers.
Therefore, when discussing PRoC LP/LPstar devices, this
manual is primarily concerned with the radio portion of the
products.
WirelessUSB LPstar
❐
■
CYRF6936-40LTXC
This manual supplements the data sheets for each of these
devices. Although there is some duplication of information
for convenience, this document goes beyond the data
sheets. Where the data sheets focus on hardware and simple register descriptions, this manual focuses on ‘how to
use’ the features discussed in the data sheet, as well as on
system level issues.
CYRF6986-40LTXC
Low Power Programmable Radio System-on-Chip
(PRoC LP)
❐
CYRF69213-40LFXC
❐
CYRF69103-40LFXC
Low Power Programmable Radio System-on-Chip
(PRoC LPstar)
❐
CYRF69313-40LFXC
❐
CYRF69303-40LFXC
All of these devices are 2.4 GHz Direct Sequence Spread
Spectrum (DSSS) transceivers operating in the unlicensed
worldwide Industrial, Scientific and Medical (ISM) band
(2.400–2.483 GHz). They add a range of enhanced features
over first generation devices, including increased operating
voltage range(only for LP), reduced supply current in all
operating modes, higher data rate options(only for LP), and
reduced crystal start up, synthesizer settling, and link turn
around times. In addition, WirelessUSB and PRoC LP/
LPstar combat interference, achieve a better wireless
communication link, and offer robust performance.
1.2
Introduction to Wireless
Wireless technologies have gained rapid acceptance in the
marketplace and the growth continues to accelerate. The
ability to move data without having to connect a cable, run
wires, or worry about having the right adapters is very
appealing. Wireless offers the promise of convenience,
speed, and ease of use.
The first thing to understand is that there are many different
wireless technologies in use or emerging today. Examples
include WiFi®, Bluetooth®, ZigbeeTM, Ultra-Wide Band
(UWB), and many more.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
13
Introducing WirelessUSB™ LP/LPstar
Figure 1-1. Wireless Technologies
Campus Area
Networking
802.16
802.15.4
Office Area
Networking
802.11a/b/g
Personal Area
Networking
802.15.1
Simple Cable
Replacement
Low
250 kbits/s
Modest
1 Mbit/s
These technologies differ in many ways, such as frequency
spectrum, data rates, data encoding, protocols, network
topologies, and others. So where does Cypress WirelessUSB technology fit in? The Cypress WirelessUSB and
PRoC products are aimed at mid to low data rates (up to
1 Mbps) and simple cable replacement or simple network
topologies.
Although there are many Cypress WirelessUSB and PRoC
products users who are experienced RF designers, the lure
of ‘going wireless’ coupled with the accessible price point
has introduced many new vendors with little or no experience with wireless products.
The Medium
Wireless technology involves transmission of information
using electromagnetic waves at radio frequencies (RF).
There are a large number of factors that can influence what
happens in this channel. Some of these factors are discussed in more detail in later sections, but here are some
simple examples:
■
Attenuation due to range
■
Attenuation due to passing through objects such as
product enclosures or walls
■
Multi-path effects from reflections off walls, floors, or
other objects
■
Interference from other signals
All of these things impact the successful transmission of the
signal from its source to its destination, and have it properly
received.
14
802.15.3
WirelessUSB
Very Low
<64 kbits/s
1.2.1
802.11n
Medium
54 Mbits/s
1.2.2
High
54 Mbits/s
Very High
>100 Mbits/s
Moving Data
Wireless is still all about moving information from point A to
point B. Depending upon the needs of the application, data
may move in one direction only, or it might need to move in
both directions. An important thing to note is that WirelessUSB only supports moving data in one direction at a time,
thus it is half duplex.
WirelessUSB systems also typically acknowledge receipt of
information. Although this feature is optional, it adds tremendously to the robustness of the system and is fully automated in WirelessUSB LP/LPstar and PRoC LP/LPstar. The
implication of acknowledgements is that even for systems
that only need to send data in one direction, there is still
communication in both directions. One side of the system
transmits its information. When the other side receives it
properly, it transmits an acknowledgement, or ACK, back to
the originating station. Thus both sides know that the data
arrived at its destination. If for some reason the originating
station did not receive the ACK within a specified time
period, it can make the decision to retransmit the data.
Systems requiring bidirectional transmission of data make
use of the above method, but interleave the
communications. This can vary greatly based on the needs
of the application, but in the simplest form Station A
transmits data to Station B. When Station B receives the
data, it replies with an ACK. At this time, Station B can send
data to Station A and Station A transmits an ACK when it
receives the data. The timing and order of these interactions
are based completely on the needs of the system.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Introducing WirelessUSB™ LP/LPstar
1.2.3
Structure of Data
In many systems where data is moved from point to point,
there is some level of framing of the data. This is as simple
as using start and stop bits on a UART to more complex
methods that allow error detection or other functions.
WirelessUSB systems have to use some level of framing,
but there are various options.
In WirelessUSB systems the data is packetized. The
transmission starts with a preamble, a preset sequence
transmitted over the air that is not part of the meaningful
data, that helps the correlator on the receiving side to
synchronize with the signal so that it can receive it properly.
There is also a limit to the amount of information contained
within a packet. In wireless systems the receiver has to
contend with distinguishing the real signal from the ever
present noise in the channel. It is not as simple as the wired
equivalent where a binary ‘1’ is 5V and a binary ‘0’ is 0V.
Therefore, there is a data limit based on the potential timing
mismatch between both sides of the system beyond which
the receive correlator can get out of synchronization with the
data stream.
Other options in WirelessUSB include using start of packet
(SOP) symbols, a length field, and a cyclic redundancy
check (CRC) field for error detection. These are also
discussed in more detail in later sections.
Figure 1-2. Sample Packet Structure
Preamble
125 Kbps mode with framing
3 byte data packet
0
SOP
32
LEN
160
Data Data Data
1
2
3
224
288
352
416
CRC
544
Time in µs
1.2.4
Protocol
1.3
Simple Network Parameters
Some simple systems plausibly just send and receive raw
data. However, to compete in the marketplace, most
products require a high level of robustness and some level
of protocol. Protocols involve an understanding by both
sides of the system as to what the specific pieces of data
transmitted mean.
For experimenting with WirelessUSB, and even for some
very simple real-world applications, it is possible to fix
certain system parameters that govern how data is
transmitted between elements in the system. But for most
real products, it is necessary to establish some level of
network.
As an example, the data portion of a WirelessUSB packet
might consist of a single header byte followed by other data
bytes. Some bits in the header byte could inform the
receiving side of the meaning of the subsequent data bytes.
For instance, they could distinguish between a packet from
a temperature sensor versus a packet from a wall switch in
a building control network. Other bits might provide status,
such as “My receive buffer is full” or “empty”. Other
elements of the protocol are sometimes used to help all
nodes in the system change channels when in the presence
of an interfering signal that is causing loss of
communication.
For now, keep the definition of ‘network’ simple and say that
it means establishing a couple of key parameters that let
specific devices communicate with one another. It may be
possible to have other devices communicating in the same
general vicinity but not interacting with the network. This is
possible by giving them a different set of network parameters.
Implementing a robust protocol is quite challenging.
Cypress has a couple of key examples that are used in
some of its reference design and development kits.
Although these are not industry standard protocols, like you
might find with Bluetooth for example, they are widely reused by its customers. Cypress has done thorough QA
testing on the examples, and these examples are in use in
high volume production with many customers.
1.3.1
Channel
The channel establishes the frequency band over which the
network transmits its data. WirelessUSB allows discrete
selections that are spaced at 1 MHz intervals. For example,
our network might transmit on frequency 2.410 GHz.
Another network in our vicinity might choose to use
2.412 GHz. The two networks can operate in proximity but
cannot exchange information with one another. From a
general standpoint, they also do not interfere with one
another because their RF energy is in different frequency
bands. The term for this is ‘co-location’. In many
applications it is desirable or even required to allow multiple
networks to be co-located in the same area without
interfering with each other’s operation.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
15
Introducing WirelessUSB™ LP/LPstar
Figure 1-3. Two Co-located Networks
Network 1
Ch 20
1.3.2
Network 2
Ch 34
PN Code
Because they use direct sequence spread spectrum (DSSS)
technology, WirelessUSB systems encode their data within
Pseudo Noise (PN) codes. The main advantage is to
increase the robustness and recoverability of the signal in
the presence of interference. A simple explanation is that a
single data bit from the application is represented by
multiple bits when sent across the air, and decoded back
into the original data bit on the receiving side.
One result of using PN codes is that devices in a given
network must agree to use a common PN code in order to
understand one another. Another advantage of this is that it
increases the co-location capabilities since devices can
share the same channel if they use different PN codes.
Devices with different PN codes but on the same frequency
cannot communicate with one another, but might present
some interference to one another. Because their RF energy
is in the same frequency band, information transmitted
within one network may be ‘heard’ by devices in another
network, even though those devices cannot ‘understand’ the
information because of the different PN code. The data may
be perceived as interference, which could impact the
reception of data if the two networks happen to have
transmissions within the exact same time interval. A robust
protocol must handle this situation with no observable
impact by the end user.
Figure 1-4. Networks on Separate PN Codes
The two networks can not communicate but may
present increased noise to one another
Circles represent
transmission range
Network 1
Ch 20
PN Code 1
WirelessUSB LP/LPstar devices also offer 1 Mbps Gaussian
Frequency Shift Key (GFSK) modes that do not make use of
PN codes. In this case, all devices on the same frequency
can communicate with one another and co-location
capabilities are potentially reduced.
1.3.3
Other Parameters
Network 2
Ch 20
PN Code 3
With CRC, an optional CRC seed can also be specified if
wanted. If used, this is one more means to allow co-location
of multiple networks. A system can reject data that is
received if it does not match the appropriate CRC seed.
Most of these other options are discussed in greater detail in
other sections of this manual.
To enable communication within a network there are other
configuration options that must be agreed upon by all
devices within the system, such as whether or not they will
be using the various packet framing options like the start of
packet symbols, length field, or CRC.
16
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Introducing WirelessUSB™ LP/LPstar
1.4
WirelessUSB LP/LPstar
Features Summary
WirelessUSB LP includes the following key features:
■
2.4 GHz Direct Sequence Spread Spectrum radio
transceiver
■
Operates in the unlicensed worldwide Industrial,
Scientific and Medical (ISM) band (2.400 GHz–2.483
GHz)
■
21 mA operating current (transmit @ –5 dBm)
■
Transmit power up to +4 dBm
■
Receive sensitivity up to –97 dBm
■
Sleep current <1 µA
■
DSSS data rates up to 250 kbps, GFSK data rate of
1 Mbps
■
Low external component count
■
Auto Transaction Sequencer (ATS)–no MCU
intervention
■
Framing, length, CRC16, and Auto ACK
■
Power Management Unit (PMU) for MCU/Sensor
■
Fast start up and fast channel changes
■
Separate 16 byte transmit and receive FIFOs
■
AutoRate™–dynamic data rate reception
■
Receive Signal Strength Indication (RSSI)
■
Serial Peripheral Interface (SPI) control while in sleep
mode
■
4 MHz SPI microcontroller interface
■
Battery voltage monitoring circuitry
■
Supports coin-cell operated applications
■
Operating voltage from 1.8 V to 3.6 V
■
Operating temperature from 0 to 70°C
■
Space saving 40-pin QFN 6x6 mm package
1.4.1
Backward Compatibility
The CYRF6936 IC is fully interoperable with the main
modes of the first generation devices, namely the
CYWUSB6934-LS and CYWUSB6935-LR devices. The
62.5 kbps mode is supported by selecting 32 chip DDR
mode. Similarly, the 15.675 kbps mode is supported by
selecting 64 chip SDR mode. In this way, a suitably
configured CYRF6936 IC device may transmit data to or
receive data from a first generation device, or both.
Backward compatibility requires disabling the SOP, length,
and CRC16 fields.
The CYRF6986 IC is fully interoperable with the main
modes of CYRF6936 by selecting 32 chip 8DR mode or
GFSK mode.
The following tables show the different configurations of the
registers and firmware that enable communication between
a second generation radio and a first generation radio.
There are two possible modes: SDR mode and DDR mode
(8-DR and GFSK modes are not present in the first
generation radio). The second generation radio must be
initialized using the RadioInitAPI of the LP radio driver and
then the following register bits must be configured to the
given byte values. Essentially, the following deactivates the
added features of the second generation radio and takes it
down to the level of the first generation radio. The data
format, data rates, and the PN codes used are recognizable
by the first generation radio.
For LPstar features please refer to the Features in
CYRF6986 datasheet and the application note-AN68105Migration of WirelessUSB™ LP Designs to WirelessUSB™
LPstar.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
17
Introducing WirelessUSB™ LP/LPstar
1.4.1.1
DDR Mode
Table 1-1. DDR Mode
Register
Value
Description
TX_CFG_ADR
0X16
32 chip PN Code, DDR, PA = 6.
RX_CFG_ADR
0X4B
AGC is enabled. LNA and attenuator are disabled. Fast turnaround is disabled, the device uses
high side receive injection, and Hi-Lo is disabled. Overwrite to receive buffer is enabled and the
RX buffer is configured to receive 8 bytes maximum.
XACT_CFG_ADR
0X05
AutoACK is disabled. Forcing END STATE is disabled. The device is configured to transition to
Idle mode after a receive or transmit. ACK timeout is set to 128 µs.
FRAMING_CFG_ADR
0X00
All SoP and framing features are disabled. Disable LEN_EN=0 if EoP is needed.
TX_OVERRIDE_ADR
0X04
Disable Transmit CRC-16.
RX_OVERRIDE_ADR
0X14
The receiver rejects packets with a zero seed. The RX CRC-16 Checker is disabled and the
receiver accepts bad packets that do not match the seed in CRC_Seed registers. This helps
communication with the first generation radio, which does not have CRC capabilities.
ANALOG_CTRL_ADR
0X01
Set ALL SLOW. When set, the synthesizer settle time for all channels is the same as the slow
channels in the first generation radio.
DATA32_THOLD_ADR 0X03
Sets the number of allowed corrupted bits to 3.
EOP_CTRL_ADR
0x01
Sets the number of consecutive symbols for noncorrelation to detect EoP.
PREAMBLE_ADR
0xAAAA05
AAAA are the 2 preamble bytes. Other bytes can also be written into the Preamble register file.
The recommended preamble bytes to be sent must be >4.
1.4.1.2
SDR Mode
Table 1-2. SDR Mode
Register
TX_CFG_ADR
Value
Description
0X3E
64 chip PN code, SDR mode, PA = 6.
RX_CFG_ADR
0X4B
AGC is enabled. LNA and attenuator are disabled. Fast turnaround is disabled, the device uses
high side receive injection, and Hi-Lo is disabled. Overwrite to receive buffer is enabled and RX
buffer is configured to receive 8 bytes maximum. Enables RXOW to allow loading new packets
into the receive buffer. This also enables the VALID bit, which is used by the first generation
radio’s error correction firmware.
XACT_CFG_ADR
0X05
AutoACK is disabled. Forcing END STATE is disabled. The device is configured to transition to
Idle mode after a receive or transmit. ACK timeout is set to 128 µs.
FRAMING_CFG_ADR
0X00
All SoP and framing features are disabled. Disable LEN_EN=0 if EoP is needed.
TX_OVERRIDE_ADR
0X04
Disable Transmit CRC-16.
RX_OVERRIDE_ADR
0X14
The receiver rejects packets with a zero seed. The RX CRC-16 Checker is disabled and the
receiver accepts bad packets that do not match the seed in CRC_Seed registers. This helps
communication with the first generation radio, which does not have CRC capabilities.
ANALOG_CTRL_ADR
0X01
Set ALL SLOW. When set, the synthesizer settle time for all channels is the same as the slow
channels in the first generation radio for manual ACK consistency.
DATA64_THOLD_ADR 0X07
Sets the number of allowed corrupted bits to 7, which is close to the recommended 12% value.
EOP_CTRL_ADR
0x01
Sets the number of consecutive symbols for noncorrelation to detect EoP.
PREAMBLE_ADR
0xAAAA09
AAAA are the 2 preamble bytes. Other bytes can also be written into the Preamble register file.
The recommended preamble bytes to be sent must be >8.
For further details, see Backward Compatibility on page 61.
18
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Introducing WirelessUSB™ LP/LPstar
1.5
PRoC LP/LPstar Features
Summary
In addition to the complete set of radio capabilities
described in the preceding section, PRoC LP integrates the
Cypress industry leading enCoRe II and Wireless enCoRe II
microcontroller technologies for a single system-on-chip
solution. enCoRe II is Cypress’s sixth generation low speed
USB controller. Wireless enCoRe II shares the same core
microcontroller technology, but in a non-USB, low voltage
configuration that is perfect for use in power sensitive wireless applications.
Additional features specific to the CYRF69213 USB device
include:
■
Integrated 3.3 V regulator (supplies radio function and
external devices)
■
Integrated pull up on D–
■
Programmable though the USB connector (programming
pins shared with D+/D–)
■
Conforms to USB Specification Version 2.0
■
Conforms to USB HID Specification Version 1.1
■
Supports one low-speed USB device address
■
Supports one control endpoint and two data end points
The microcontroller function adds the following key features
to both PRoC devices:
■
Integrated USB transceiver with a second dedicated
3.3 V regulator
■
M8C based 8-bit CPU, optimized for HID applications
■
Operating voltage from 4.0V to 5.5 V DC
■
No crystal required for the microcontroller–operates
independent of radio crystal’s state
For PRoC LPstar features please refer to the Features in
CYRF69303/313 datasheets.
■
8K bytes of Flash memory with EEPROM emulation
■
256 bytes of SRAM
■
In-system re-programmable
■
16 bit free running timer
■
Low power wake up timer
■
12 bit programmable interval timer with interrupts
■
Watchdog timer
■
High current drive on GPIO pins. Configurable 8 mA or
50 mA/pin current sink on designated pins
■
Each GPIO pin supports high-impedance inputs, configurable pull up, open-drain output, CMOS/TTL inputs and
CMOS output
■
Maskable interrupts on all IO pins
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
19
Introducing WirelessUSB™ LP/LPstar
1.6
Block Diagrams
1.6.1
WirelessUSB LP/LPstar
The WirelessUSB LP chip is comprised of two main functional blocks; one is the radio core and the other is the radio control/
baseband logic. For LPstar, please refer to the Logic Block Diagram in CYRF6986 datasheet.
Figure 1-5. WirelessUSB LP Block Diagram
VIO
VBAT
VREG
L/D
VDD VCC
Power Management
IRQ
SS
SCK
MISO
MOSI
SPI
Data
Interface
and
Sequencer
RFP
GFSK
Modulator
RFN
RFBIAS
DSSS
Baseband
& Framer
GFSK
Demodulator
RSSI
Xtal Osc
Synthesizer
RST
Block Diagram
XTAL
XOUT
1.6.2
PACTL
GND
PRoC LP
As discussed in section 1.5 PRoC LP/LPstar Features Summary on page 19, PRoC LP integrates the radio and microcontroller functions in a single package. The inner blocks of the radio function are equivalent to those shown in Figure 1-5.For
PRoC LPstar, please refer to the Logic Block Diagram in CYRF69303/313 datasheets.
20
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Introducing WirelessUSB™ LP/LPstar
Figure 1-6. PRoC LP CYRF69213 Block Diagram
1ohm
nSS
VIO
VCC3
VCC2
VReg
VCC1
VBat0
VBat2
P1.2 / VReg
VBat1
470nF
RST
MOSI
1-2 uF
VDD_MICRO
4.7uF
SCK
Vbus
RFbias
RFp
RFn
P0_1,3,4,7
Microcontroller
Function
4
Radio
Function
IRQ/GPIO
P1.5/MOSI
P1_6:7
2
MISO/GPIO
P1.4/SCK
P2_0:1
XOUT/GPIO
P1.3/nSS
2
PACTL/GPIO
.....
VSS
GND
GND
Xtal
GND
RESV
D+/D2
.......
12MHz
470nF
Figure 1-7. PRoC LP CYRF69103 Block Diagram
nSS
V CC
SCK
MOSI
47µF
V CC
470nF
VIO
VCC3
VCC2
VCC1
VReg
L/D
VBat0
VBat1
VBat2
VDD_MICRO
RST
10µF
RFbias
RFp
RFn
Microcontroller
Function
4
IRQ/GPIO
P1.5/MOSI
MISO/GPIO
P1.4/SCK
P1_0:2,6:7
5
XOUT/GPIO
P1.3/nSS
PACTL/GPIO
12MHz
.....
GND
GND
RESV
Xtal
GND
P2_0:1
2
.......
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Vdd
P0_1,3,4,7
Radio
Function
470nF
21
Introducing WirelessUSB™ LP/LPstar
1.7
Device Options
Table 1-3. Device Options
Device
Part Number
MCU
USB
Memory
Operating
Voltage
Vreg Output
Boost Output
2.4–2.7V
WirelessUSB LP
CYRF6936-40LTXC
N/A
N/A
N/A
1.8–3.6
N/A
WirelessUSB LPstar
CYRF6986-40LTXC
N/A
N/A
N/A
2.7–3.6
N/A
PRoC LP
CYRF69213-40LFXC
M8C
N/A
8K Flash
4.0–5.5
3.3V
N/A
PRoC LPstar
CYRF69313-40LFXC
M8C
N/A
8K Flash
4.0–5.25
3.3V
N/A
PRoC LPstar
CYRF69313-40LTXC
M8C
N/A
8K Flash
4.0–5.25
3.3V
N/A
PRoC LP
CYRF69103-40LFXC
M8C
Low Speed
8K Flash
1.8–3.6
N/A
2.4–2.7V
PRoC LPstar
CYRF69303-40LFXC
M8C
Low Speed
8K Flash
2.7–3.6
N/A
PRoC LPstar
CYRF69303-40LTXC
M8C
Low Speed
8K Flash
2.7–3.6
N/A
22
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
2. Design Considerations
2.1
Introduction
Wireless systems are complicated. Engineers have to manage all of the standard challenges associated with any electronic design, but there are now added dimensions in the
mix. By definition a wireless system involves multiple nodes
that must exchange data asynchronously. Without a physical connection there is not even assurance that data
reaches its destination. Getting proper RF performance out
of a product can be a multifaceted design effort in and of
itself.
Although there are many RF knowledgeable designers
using WirelessUSB, there are many more who are
approaching wireless for the first time. Introducing WirelessUSB™ LP/LPstar, on page 13 already pointed out the lure
of wireless: the capabilities wireless technology brings to the
table, combined with the approachable price point have
driven many companies to make the move to wireless for
their products. But they often make this move without a full
understanding of all of the system requirements that must
be taken into account. Even experienced designers may
want to go back to the basics every now and then to make
sure they are not forgetting key points.
The purpose of this chapter is to review many of the considerations that must be taken into account before starting
work on a wireless project. The intent is not necessarily to
provide solutions, but to make sure that designers are
aware of the right questions to ask themselves before diving
into the design work. It is placed in front of much of the technical information concerning the WirelessUSB products for
that very reason.
As with any complex project, forethought and careful
advanced planning can keep a project on track, minimize
risk, prevent unnecessary rework, and result in a product
that has the right level of appeal to customers in its target
market space. This chapter is intended primarily for system
architects who will define the specifications for their project,
but it may also be valuable to marketing personnel who will
lay out the initial product feature requirements.
2.2
Power
For many wireless designs, power is one of the most critical
considerations. One thing is almost certain: for a wireless
system, the overall system power consumption will almost
certainly be greater than that for a wired equivalent system.
So where power budget may have been of trivial consequence in a legacy wired product, as companies move to
wireless technology they may find that they have to put additional constraints on their design to manage power.
2.2.1
Power Source
There are two important distinctions to draw with respect to
the power supply. Devices are generally supplied from a
source that is either essentially limitless, or from batteries
where the supply has a significant limit. One other key thing
to note is that a complete system may involve different
nodes that fit under different categories.
2.2.1.1
‘Unlimited’ Power Supplies
Although the term ‘unlimited’ is used, this is generally only to
set it apart in order of magnitude from battery powered products. Even devices with effectively limitless power supplies
probably still have a power budget. Draining batteries may
not be a concern, but there are other factors, such as heat
generation, that may place limits on the system.
Devices that derive their power from a wall power supply
certainly fall into this category. Devices that draw their power
from other systems can also fit this category. As a specific
example, consider a product that plugs into a USB port and
uses USB as its power source.
The key characteristic of devices that fit into this category is
that they have the flexibility to choose any operating mode
of the radio without regard to power consumption. In simpler
terms, a radio could stay in receive mode constantly so that
it is ready to receive information at any instant.
Revisiting the USB example, note that both desktop PCs
that plug into the wall, as well as laptops with their own battery are placed in this category. The laptop is considered to
have a power source of a significantly large order of magnitude that it does not place significant constraints on the
operation of the device. So although devices in this category
may still have power budget concerns, the flexibility of oper-
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
23
Design Considerations
ating the radio in any mode takes precedence, and power
considerations become a secondary issue.
2.2.1.2
Battery Powered Devices
In contrast with the above category, battery powered
devices have a limited source of power, and must operate in
a constrained fashion to effectively use the power supply.
‘Battery life’, the amount of time that the product can operate
without replacing or recharging batteries, is likely to be a key
marketing metric.
The constraint on these devices is that the radio will not be
able to operate in any mode desired at any time. Radios
have different operating modes with varying levels of current
consumption. For example, WirelessUSB LP/LPstar devices
have sleep, idle, synthesizer settle, transmit and receive
modes, each with their own power consumption numbers.
There are trade offs in responsiveness with respect to the
different modes as well. Staying in transmit mode means
that the radio can transmit a packet at any instant with negligible latency, but it consumes a high amount of current.
Conversely, keeping the radio in sleep mode consumes negligible current, but means that it will take a relatively long
time to wake up the radio and ready it for transmitting data.
Within transmit mode there are also varying Power Amplifier
(PA) levels that have different transmit power levels with a
corresponding current consumption. Higher PA levels mean
longer range, but greater power consumption.
Battery powered devices will typically have to define various
operating modes that balance power consumption with other
parameters such as responsiveness or range. These modes
may apply to the radio, but they may also apply to other IC’s
in the device such as external microcontrollers, optical sensors, and others. A typical device might be in sleep mode for
a substantial period of time. It could then wake up based on
a predefined interval or event, at which time different portions of the system can be powered up to perform appropriate tasks, such as the transmission of data.
2.2.2
2.2.3
Voltage Range
Voltage range is generally a much less complicated issue,
but it is dealt with here only because there are different
capabilities of the WirelessUSB LP/LPstar and PRoC LP/
LPstar products that may have an effect on the system
power consumption.
A given device typically contains multiple IC’s that may have
different operating voltage requirements. WirelessUSB LP
contains the PMU that can power the radio as well as external devices at 2.4V–2.7V levels when boosting from
1.8V(LPstar doesn’t support this). PRoC LP contains the
same PMU, and the CYRF69213 version also contains a
regulator that can supply 3.3V to itself and external devices
from a 5V supply(CYRF69313 also supports this). Both of
these power management systems have current limits that
must be taken into account, as well as different capabilities
in sleep and awake operating modes.
Designers must identify the voltage and current needs of all
devices in the system and assess if the PMU or voltage regulator are required, or appropriate, for the system. All operating modes of different IC’s in the system must be taken
into account. In some cases an external component may be
required, such as a battery powered device with another IC
requiring a minimum of 3.0V. In this case the PMU is unable
to boost to that level and an external DC-DC converter may
be required. The designer may still have to determine if the
DC-DC converter will supply all devices on the board, or if it
will power only that IC while the PMU manages power for
the radio. There will be trade offs in cost and efficiency that
have to be considered.
Peak and Average Current
Given that the IC’s in the circuit will operate off of given voltage levels, the real parameter to analyze is current.
Peak current for a given operating mode can be a significant
parameter, but generally only for devices that will keep the
radio in a high power mode for a long period of time. This is
typically only going to occur for those with unlimited power
supplies. The primary example would be a device that keeps
the radio in receive mode constantly in order to be ready to
receive a packet at any time. The WirelessUSB LP/LPstar’s
maximum Rx power parameter would probably be the one
used in power budget calculations.
For devices, especially battery powered devices, that vary
the operating mode of the radio frequently, average current
is typically a much more significant metric. There are different profiles here, such as devices that alternate between
24
transmit and receive constantly, but the more likely profile is
one in which the device stays asleep for most of the time,
and then wakes up, performs some task such as transmitting a packet, and then goes back to sleep. In this case the
time in each mode versus the corresponding current consumption should be evaluated to determine the true power
consumption of the device.
2.3
Range
For wireless systems the distance over which information
can be transmitted is obviously a key concern. But range is
also a complex parameter with many factors affecting the
achievable range in a real world environment. In general,
range varies directly with the output power of the transmitter.
Receive sensitivity of the receive side also plays a factor.
Some of the high level interactions in the channel were discussed in the section "The Medium" on page 14. Between
the transmitter and receiver the signal are attenuated by
spreading, passing through objects, and interactions with
other signals or its own reflections. The power and noise levels between the transmitter and receiver as well as all of the
gain and loss factors between them define the link budget.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Design Considerations
Marketing or systems architects must determine if there is a
range requirement for the system. They should also attempt
to define the environment in which the system is expected to
be used. Examples include out door line-of-sight, in a home
where there are lots of walls to pass through, or in an office
environment where there may be a large open space but
filled with many cubicles. Is a significant amount of interference expected? These items are external factors over which
the designers have little control, however they do affect the
link budget, so they must be taken into account first. At a
first level this analysis determines if the product is even viable. From there the system architect can move to an evaluation of internal factors.
As with most parameters, range can be trade off against
other items. If the link budget is not sufficient then what can
be done to increase it? Or if it is above the requirements
then it may be possible to drop it down to a minimum
acceptable level, and thus make gains in other parts of the
system.
Different transmit powers obviously produce different maximum ranges. Data rates also have an impact. WirelessUSB
products have many data rates to choose from with their
own sets of trade offs. Component selection also has an
impact. RF performance can be impacted by power supply
noise, antenna type, antenna matching, crystal oscillator
performance, and other factors. There are many component
choices that can directly impact these factors. As a general
rule, more costly components produce better performance.
2.4
Throughput
Knowing how much data must be moved through the system is another significant point to define. There may be different operating modes of the system that might have their
own throughput requirements so each must be considered
separately. From this starting point, other key parameters
can be defined.
2.4.1
Data Rate
For high data rate systems (‘high’ with respect to WirelessUSB’s capabilities) throughput is probably most closely
related to data rate. The necessary throughput may determine if there is a minimum date rate that is acceptable for
the application. When conducting this analysis do not forget
to take into account the packet framing. There is overhead
associated with every WirelessUSB packet (discussed in
more detail in section "Payload Size" on page 25). High data
rate wireless systems will also probably require the radio to
be ON a large portion of the time and may not be able to
take advantage of the sleep-wake cycle discussed in section
"Battery Powered Devices" on page 24.
Even if the required throughput is low enough to support any
data rate, there may still be benefits to higher data rates.
The ‘chip rate’ for WirelessUSB is constant at one million
chips per second regardless of the actual data rate selected.
Two different PN code lengths, three different data encoding
schemes, and a GFSK mode all contribute to the range of
data rates available. If data is moved at a faster rate, the
transmission is completed quicker; thus the radio can be
moved from a high power mode to a low power mode more
quickly resulting in moving the same amount of data at a
lower power consumption.
There are trade offs, of course. Higher data rates are theoretically more subject to interference. This is certainly true of
GFSK mode, without the benefits of DSSS to help recover
data bits when chip errors occur. For the DSSS modes the
performance may not be entirely as expected. The radio is
designed around 8DR mode, and users will find that it is
most effective at transmitting data in this mode. Within any
given encoding scheme (8DR, DDR, and SDR) the 32-chip
options are generally less effective than the 64-chip options
at delivering data across the channel without the corruption
of bits.
2.4.2
Payload Frequency (Report Rate)
Payload rate may only be an option for systems that have a
low enough throughput rate that any or most of the data
rates are available to them. For example, audio systems
that require large amounts of data may find that they must
keep the radio in transmit or receive modes constantly.
Compare this to building automation systems with sensors
that only need to transmit reports at an infrequent interval.
And of course, there are systems with requirements that fill
the entire spectrum between these two examples.
Systems that sleep between packets for power savings also
need to analyze the maximum interval that they can spend
asleep in order to meet the throughput requirements. This
can also be closely related to latency that is discussed in the
section Latency on page 26.
2.4.3
Payload Size
If it is necessary to transmit 20 bytes across the link, is it
better to transfer one 20 byte packet, twenty 1 byte packets,
or something in between? There are a couple of things to
keep in mind when considering the payload size.
The first thing to consider is that there is overhead associated with each packet. Exactly how much varies with a number of the configuration options available with WirelessUSB.
Once these options are selected, you can expect the overhead to be consistent regardless of the size of the packet.
Therefore, it is generally more efficient to transfer larger
packets.
The next thing to consider is the impact of bit error rate
(BER). In a given environment with a fixed set of configuration options there is a probability that any given bit may be
corrupted when it is transmitted. At the lowest level, is the
probability of a DSSS chip being corrupted. The tolerance
thresholds manage this to some extent, but with a set number of chips making up each bit you can still calculate a the-
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
25
Design Considerations
oretical probability of an actual data bit being corrupted. This
probability is the same for every bit; therefore, the more bits
that are sent the greater the probability that any error occurs
in the packet.
WirelessUSB LP/LPstar does employ a CRC mechanism to
help detect errors, but there is no a built-in error correction
capability. Although error correction could be added in software, there may also be a packet size penalty to pay for
that. For the moment, only consider that if an error occurs, it
is necessary to retry sending the packet again if accurate
delivery of data is essential.
Thus, there is a conflict. Larger packets are more efficient,
but they may also be subject to a higher probability of failure
and require retransmission, therefore increasing overhead in
another way. Finding the critical point where the balance
shifts one way or the other may require experimentation
under the conditions required for the application.
There is one final consideration when dealing with larger
packet sizes. Keep in mind that WirelessUSB LP/LPstar has
a 16 byte data buffer. This is significant particularly for battery powered devices that need to minimize power. For
packet lengths up to 16 bytes it is possible to sleep the
microcontroller after the packet is initiated because the
radio’s Auto Transaction Sequencer (ATS) can manage the
transmission without microcontroller intervention. For packets lager than 16 bytes it is necessary for the microcontroller
to be awake at least periodically to manage buffer over- or
under-flow conditions. Therefore, it might be beneficial to
break large packets into chunks less than or equal to 16
bytes.
2.5
Latency
Latency defines the amount of time between the occurrence
of an event and the response to that event. Identifying the
event is usually fairly simple; for example, the press of a button. Identifying the end point is a bit more tricky.
Consider a wireless keyboard. From an end user perspective the latency that is most important is from the time a key
is pressed until the character is displayed on the screen.
The problem is that this is not easy to measure. The engineer cannot hook up an oscilloscope and trigger on when a
character appears on the screen. And the handling of the
keypress by the operating system cannot be determined.
Even if we know when the data was handed to the PC hardware, there is no set delay until it appears on the screen.
Therefore, this definition is not useful. A more viable option
is to measure when the receiving radio passes the key data
to a microcontroller over the SPI interface, or when a USB
packet with the data is transmitted to the USB host controller.
The point to be made here is that a useful definition of
latency must be set, and then you can analyze the factors
that impact it. Some of these may be related to the wireless
portion of the system but others may not. The latency
26
related to transmission of a packet over USB is an excellent
example. It adds to the overall latency of the system and
designers will have to account for it.
From a wireless perspective there are a few things that can
effect latency. Payload frequency is probably the most critical. If the system goes to sleep for 1 ms and then wakes up
for a brief interval to transmit data, then there is a potential
latency of 1 ms due to the wireless link. Data rate also has
an impact. Slower rates take longer to transmit the data.
The most obvious trade off here is power consumption. But
there are also some other subtle things to consider. For
example, the WirelessUSB LP/LPstar radio does not
respond the same on all channels. The Synthesizer takes a
different amount of time to settle for slow, medium, and fast
channels. From both a latency and power consumption
standpoint, it might be best to manage channels as oppose
to preferentially always using the fastest channels. But this
may add to code size and complexity.
2.6
Link Architecture
Link architecture defines the type of network being created.
To a large extent this may be defined by the type of product
that is being built, and thus might be a non-issue. But in
some cases there may be options for how to construct the
link. And in either case, understanding the architecture contributes to an understanding of the system requirements and
trade offs.
2.6.1
Topology
Topology is the most relevant topic with respect to link architecture. This refers to the physical structure of the link and
how devices relate to one another. Some sample topologies
include:
One-to-One. An example of this might be an RS232 cable
cutter. Two nodes that used to be connected through an
RS232 cable are now moved to a wireless link.
Star Topology. This type of network has one or more
nodes that communicate with a central device. Cypress’s 2way HID designs and N:1 both fit into this general category.
Mesh. In a mesh network, individual nodes communicate
with one another without having to go through any central
point.
2.6.2
Number of Devices
It is important to define the number of devices that are
allowed on the network. In the start topology examples
above, both the 2-way HID and N:1 designs were mentioned. In 2-way HID there is generally one mouse and one
keyboard that communicate with one PC-based bridge,
although there is some allowance for a ‘few’ other devices,
such as a presenter tool or remote control. In N:1 there are a
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Design Considerations
large number (up to about 65,000) of sensor or actuator
nodes that are linked to one central hub.
These could both be considered star topology, but there are
very different protocols put in place to manage the different
numbers of devices. Therefore, defining the number of
devices can have a drastic impact on the details of the communication protocol and link layer of the system.
With small numbers of devices, collisions may be very infrequent and easily managed, relatively high throughputs may
be supported, and latency can be kept small. Large numbers of devices may require substantially different ways of
thinking about the link. Significant collision handling and
retry mechanisms may be required, time division access or
a broadcast mechanism to provide link framing might be
instituted. Long latency might have to be required or a priority mechanism for certain nodes or types of data might be
needed.
2.6.3
Direction
Direction sounds fairly simple, but it can also touch on some
other more complicated definitions.
Most simply, direction defines which way information is
transmitted. Most WirelessUSB systems will probably use
ACKs to provide notification that data was received by the
other end of the system, but this might not always be the
case. Even if ACKs are used, meaning that bidirectional
communication is taking place, the actual data flow may be
only in one direction such as from a sensor to the central
hub.
There are also many cases where data predominately flows
in one direction but it may be necessary to occasionally
transmit in the other direction. Because the data that is
transmitted in the ‘backwards’ direction is infrequent, it might
be possible to have different, less efficient means of handling it.
Direction of data flow can also be tied to the power consumption and operating modes of the devices. Look at a situation where data is transmitted in only one direction, such
as from a sensor to a central hub. If the hub has an unlimited power supply and the sensor is battery powered then
the hub can listen constantly, and the sensor can wake up to
transmit only when required. Direction and power management are compatible with one another. But what if the hub
was also battery powered and could not effectively listen at
all times. This can greatly complicate the system architecture. It might be necessary to provide some mechanism for
synching the two devices. For example, the hub might send
out a broadcast packet at some interval signifying that it is
ready to listen. A sensor with data to transmit might have to
listen for the broadcast packet before sending its data.
Direction also leads into the concept of ‘who’ communicates
‘when’. One way to look at this is the concept of Master and
Slave but this can get into gray areas. Consider the example
of a wireless mouse. If we looked at the wired equivalent
connected through the USB port, the PC is the master and
the mouse is the slave. The mouse only sends data when
the USB host first sends an IN token to the device.
But in the case of our wireless mouse, power constrains the
system. The bridge on the PC can be listening at all times,
but the mouse must conserve power and so it sleeps most
of the time and only wakes up periodically to transmit a
packet. The mouse is the master of the communication link.
It decides when to transmit data, which is the opposite of the
USB case.
To confuse matter more, look at the interference avoidance
aspects of the system. Since the PC bridge is always in
receive mode, it is ideally suited to monitoring the environment, detecting interference, and selecting a new channel
when required. Thus the bridge is the master from the perspective of channel selection.
Many vendors use the term ‘transmitter’ and ‘receiver’. This
works fairly well for devices that predominantly transmit in
only one direction. Again, the wireless mouse is a good
example. The data flow is almost always from the mouse to
the bridge. The mouse would be defined as the transmitter
and the bridge is the receiver. Just bear in mind that when
ACKs are transmitted these two devices swap radio modes:
the receiver transmits the ACK and the transmitter receives
it.
This discussion is primarily semantics, but it highlights a
common communication problem that arises around wireless systems. The take away is to define terminology early
and try to find a good fit based on the system functionality.
As an example, Cypress has used the terms ‘node’ and
‘hub’ for its N:1 designs, which are roughly equivalent to the
terms ‘device’ and ‘bridge’ that it uses for its HID designs.
2.7
Interference Avoidance
The ISM band is a busy spectrum with a lot of different technologies sharing the band. Therefore, managing interference is an important consideration. One of the strengths of
the Cypress WirelessUSB solutions is their immunity to
interference. This is a combination of the radio technology
and the algorithms employed in the solutions. System architects must consider what types of environments are
expected, and how much effort must be placed on managing
interference.
The DSSS technology itself is the first stage of managing
interference. Individual chips may be corrupted due to interference, but the fact that a single data bit is encoded with 64
or 32 chips means that it is still possibly to recover the data
on the receiving end. The tolerance for how many bits can
be lost before rejecting a packet is a parameter that the
developer controls. Cypress has defaults that we recommend in our solutions, but this is something that vendors
may want to evaluate in the expected environment for their
products. This discussion also highlights the fact that devel-
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
27
Design Considerations
opers must think carefully before using the GFSK mode of
the radio since all of these benefits are lost.
In the presence of stronger interference, the DSSS technology by itself may not be enough to overcome interference.
Recall that we have already touched on the effects of PA
level and data rate in other sections. Increased PA level, and
certain data modes can improve the maximum range of a
system, which also means they can help to overcome interference at shorter ranges. Using these techniques must be
balanced against power consumption, and potentially even
throughput and latency.
Up to this point we have only discussed mechanisms for
overcoming interference. But interference can also be
avoided entirely. There are two stages here. The first is
detecting the interference, which can be accomplished with
different methods. WirelessUSB has the capability to measure signal strength, which can be used to monitor the background noise level. Other techniques, such as monitoring
packet error rate, can also be employed. Once interference
has been detected, the system must then identify a channel
with an acceptable level of interference, and then move all
nodes on the system to this new channel. The method of
communicating the move to all nodes in the system can be
somewhat complicated. System architects will have to consider their options, such as attempts to actively communicate the channel change to other nodes, versus a passive
mechanism where a master station moves and it is up to
other nodes to seek out the master on its new channel.
2.8
Co-Location
Co-location refers to the number of systems that can operate in close proximity to one another. ‘Close’ means within
communication range. They key is that from a co-location
perspective you usually do not want the systems to be able
to exchange data with one another.
A classic example is wireless keyboard and mouse systems
in an office environment. There may be dozens of systems
within about 10 meters of one another–well within the range
at which they can communicate. The requirement is for each
keyboard and mouse to be able to exchange data with its
own PC, but they should not send data to any other PCs in
the office. It would be very problematic if one person typed
on his keyboard but the characters showed up on the screen
of another employee a few desks away.
In addition to preventing the separate systems from
exchanging data with one another, it is also important that
the systems not interfere with one another, causing loss of
data or excessive retries. Managing co-location can be
achieved in a variety of ways. For WirelessUSB LP/LPstar
systems the primary mechanisms are to distinguish systems
based on channel, PN code, and CRC seed. There are trade
offs associated with each of these parameters. These topics
were also discussed earlier in Simple Network Parameters
on page 15.
28
Designers have to determine how many systems may need
to be co-located together. This has to be weighed against
the interference environment, and possibly even other considerations, such as throughput. If only a few systems ever
need to operate close together, then separation by channel
may be sufficient. But channel selection is also part of the
interference avoidance technique. Therefore, if there are
more systems, PN code and/or CRC may need to be used
as well. If the throughput requirements are high, then
designers also have to consider the effects of two systems
sharing a channel, but on different PN codes or CRC seeds.
Systems on different PN codes may still see each others
transmissions as increased noise. And systems that are only
differentiated by CRC seed actually have to share bandwidth; they will receive each other’s data and reject it only
after evaluating the CRC seed.
2.9
Transfer Type
Transfer Type refers to the type of data and carries an
assumption of how it will be handled within the system. A
close analogy to this would be USB data transfer types,
such as bulk and isochronous data. In USB, bulk data has a
guaranteed delivery but not necessarily a guaranteed timing. If a transfer fails it will be retried until it succeeds. It also
receives a lower priority compared to other types of data and
so may not be transmitted across the link as soon as it is
available.
In contrast isochronous data is time sensitive. It is guaranteed a certain amount of bandwidth in the link and is transmitted with a high priority. But it also does not have
guaranteed delivery. If an isochronous packet fails, USB
does not retry it and the data is permanently lost.
Similar concepts may also have to be applied to wireless
systems. System designers must understand how different
types of data will be used in the system and determine the
relative importance of things like guaranteed delivery, priority, and timing. Answers to these questions will have significant impact to the construction of the protocol that will be
used to manage the link.
2.10
Binding
The industry uses various terms for the concept of binding
such as pairing, connecting, and others. These all describe
the mechanism by which a network is created or by which
new devices are added into an existing network. This can be
a very complex topic, especially for consumer devices
where the end user must clearly understand what he is
required to do to set up the system. For commercial or
industrial systems where the network may be configured by
a technician, it might be less of an issue.
Cypress has a separate application note, Wireless Binding
Methodologies, that discusses this topic in more detail so it
will only be reviewed at a high level here. Binding can be
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Design Considerations
achieved in many different ways so the system architect
must think very carefully about the user experience that is
required during the process, under what conditions it can
occur, and how resistant it is to failure.
Examples of binding options include:
■
Binding in the manufacturing process, such as through
use of special test software/hardware
■
Binding that occurs as a result of a user action, such as
pressing buttons
■
Binding that occurs upon the power up sequence of a
device
■
Binding that can occur in a dynamic or ad-hoc basis,
such as whenever a device comes in proximity of a network
■
Completely manual binding, such as selection of the
channel through a switch, or entering parameters via a
software interface
There are many trade offs that have to be considered so this
topic should be dealt with early so that impacts on the rest of
the system can be fully understood.
2.11
Footprint
Footprint is relatively simple to discuss. It simply refers to
how large the physical solution is. A good example of where
this is important is a wireless presenter tool which includes a
USB dongle for the connection to the PC. Because the tool
is made to be transported around, the dongle is made to
slide into a small compartment in the presenter tool itself.
Therefore, form factor is a critical requirement.
One of the main advantages of the PRoC LP device over
the WirelessUSB device is form factor. PRoC LP/LPstar
includes the microcontroller function in the same physical
package that is used for just the radio in WirelessUSB LP/
LPstar. Therefore designers can save the space required by
the microcontroller.
There are other options for reducing size, but they do have
their cost. Smaller components can be chosen for things like
the crystal and discrete components for the PMU, matching
network, and filters. These smaller components may have a
higher cost, or may have performance limitations compared
to larger devices. The design of the antenna is also a factor,
particularly for PCB trace antennas that are typically used in
small form factor designs. These small antennas may have
performance limitations compared to other options.
2.12
Cost
Cost is almost a trivial topic by the time that all of the preceding items have been discussed. Everything has a cost
associated with it, and obviously marketing and system
designers must consider these costs to ensure they have a
viable product with the right set of capabilities for the price
point. Costs can occur up front in the design of the product
or set up of manufacturing, or they can be born over the life
of the product due to the bill-of-materials (BOM) and production costs. In some cases these might even be traded
against one another. They are certainly traded against
almost every other topic in this chapter.
2.13
Time-to-Market
Time-to-market is another fairly straight forward concept,
even though it may be difficult to minimize in practice. It can
have vast implications for product success and may require
hard decisions for the developers. One of the most important factors in achieving the desired time to market is going
through the topics in this chapter, thinking about them thoroughly, and then making and documenting appropriate decisions based on the requirements of the product. At the very
least this will help set reasonable expectations for all members involved on the product development team.
2.14
Manufacturability
This is not a topic that will be addressed in detail, but it is still
worthy of mention. Wireless designs, especially those pushing the performance limits, may face manufacturing challenges. This can especially be the case when manufacturing
is intended for low cost facilities where the equipment available may not exactly be cutting edge. This will probably be
one of the later topics looked at during the product analysis
and specification, but it should still be examined before the
design work starts. Many of the preceding questions will
need at least preliminary answers to determine if there are
any manufacturability concerns. Any manufacturing partners
should also be consulted to understand their capabilities
and limitations.
2.15
Testing
Testing is a topic that is not given its fair mind share far to
often. It is often critical to overall success of the product.
There are a few different aspects to consider, but all of them
must be considered before the design work starts. The system must be designed for test from the start, because it is
usually difficult to go back and add test capabilities after the
fact.
2.15.1
System Quality Assurance
This is basically acceptance testing of the product once the
design work is complete. The bulk of it is focused around
building test cases that fully exercise the product’s capabilities. Often special test modes might be required in the
device to make sure that corner cases are being addressed,
or to manage all of the test requirements efficiently.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
29
Design Considerations
2.15.2
Regulatory
RF products will have to pass regulatory test requirements
such as FCC, ETSI, or TELEC, depending upon the regions
in which they will be sold. These test will all require that the
product be put into certain operating modes. As a result
these must be considered at the start so that the product
includes firmware, or controls, to enter the test modes.
There may be non-RF tests that fall into this general category as well, so designers must consider all testing that
might be required. Examples include USB compliance, Windows compatibility testing, electromagnetic interference
(EMI), electrostatic discharge (ESD), or electrostatic fast
transient burst (EFTB) testing.
2.15.3
Manufacturing
Wired products can often rely on functional tests to thoroughly evaluate that the device is ready for shipment.
Although functional tests are necessary for wireless products, it is usually a good idea to also include RF testing. RF
testing is typically used to evaluate that there are no manufacturing defects that would impact the range or RF performance of the device. This type of testing is typically
accomplished using a shielded chamber. The signal path is
intentionally attenuated to simulate longer range conditions.
Then packet or bit error rates are measured during data
transfer to evaluate if the system meets the desired requirements. The Cypress CY3631 Manufacturing Test Kit provides an excellent reference for adding RF testing to the
production line
30
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
3. Resets
3.1
Introduction
When designing for the WirelessUSB LP/LPstar or PRoC
LP/LPstar, there are three types of radio resets to consider;
each is subsequently discussed.
■
Power On Reset (POR)
❐
POR via capacitor
❐
POR via microprocessor
■
Hard Reset
■
Soft Reset
When power is first applied to the radio, it typically takes a
finite period to achieve the designed operating voltage
range. During this time, the microcontroller may be required
to maintain a specific state on its output pins and hold off
any execution of register initialization code until the radio is
stable.
The reset (RST) pin is an input that resets the entire chip
when power is applied to the radio. The RST pin must be
brought high momentarily upon power up. This pin can also
be used during a system-wide reset event. When the RST
pin
is
high,
the
clock
will
not
run.
The
MODE_OVERRIDE_ADR.RST bit only resets the registers
to their default values; it does not reset the entire chip.
A simple function such as reset can cause many problems
since different applications impose very different conditions
on the start up and power down of the radio. This chapter
covers the main types of resets and aims to lead the user to
a proven reset strategy by providing straightforward recommendations. Reset in its most basic form ensures that the
radio functions in a controlled manner during normal device
operation.
The parameters affecting reset are explained in detail in this
chapter. In most applications several factors apply and so it
may be a combination of these elements of reset functionality that must be considered to establish consistent and reliable radio communications.
3.2
Power On Reset
The radio must sense a POR event when power is applied
to the radio otherwise the state of the radio control registers
is unknown. The POR event is a RST pulse (VRST) that must
rise above VIH (0.7*VIO) and must hold that level until the
VCC, VREG(for LP and PRoC LP only), and VDD pins are
greater than the minimum VBAT which makes sure that all of
the logic across the supply boundaries have sufficient supply voltage to function properly as logic. RST may be held
high longer.
If this event does not occur (or is not successful), you may
end up with some devices that turn on in a mode that draws
supply current or otherwise behaves in some undesirable
way. RST can be high before power is applied, or it can
ramp up together with VBAT. This is what an external capacitor does automatically if sized correctly relative to the power
up ramp rate.
RST must remain low for the remainder of the operating
session. Performing an initial POR event is the only way to
guarantee consistent, repeatable start up behavior part-topart and run-to-run. Those radios that do not function correctly after an incorrect POR event will not be recovered by
strobing the RST pin at a later time. Therefore, a correct
POR event is the only way to ensure proper functionality of
the radio.
Upon completion of a POR event, the internal configuration
registers revert to their default states. These values may be
found in the device data sheet, see Cypress Semiconductor
Support on page 9. Several registers must be changed or
controlled during normal radio operation at other than their
default settings. After a POR event, initialize radio registers
via SPI communications to the radio interface.
SPI access is available during and after the POR event. The
registers are accessible even during reset. However, writes
have no effect until the RST pin is below the VIL threshold. It
is recommend that initialization firmware poll a radio register, XACT_CFG_ADDR at address 0x0F, by writing a nondefault value of 82h to it while reading it back; when it successfully reads the contents of the register, it is an indication
that it is safe to begin radio register initialization.
3.2.1
POR via Capacitor
The recommended method to ensure the POR event is successful is by placing an external capacitor (for example,
0.47 µF) tied to VBAT and internal pull down resistor
(10K ohm) with VBAT settling within 2 ms. It is recommended
that the external capacitor is X5R (for example, Kemet
C0402C474K9PACTU) which has a ±15% maximum capac-
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
31
Resets
when VBAT settles within 2 ms generates VRST of at least
1.26V (that is, 0.7*VIO) when VIO is 1.8V. In this example,
the POR event to RST low (VIL) event takes approximately
10 ms. This is a typical time and will vary with capacitor tolerance, process, temperature, and voltage.
itance shift over -55C to +85C, see Figure 3-1 on page 32.
For LPstar, place the same capacitor to VBAT as the recommended POR circuit of LP.
If an external capacitor is used to provide the POR event,
the value of the capacitor must be selected and VBAT ramp
controlled such that VRST is met under all conditions. For
example, using the recommended external capacitor value
Figure 3-1. Recommended Power On Reset Circuit of LP
VBAT
0.47uF
NC
31
35
32
VDD
36
NC
NC
37
33
L/D
38
VIO
VBAT0
39
34
NC
40
RST
VREG
Corner tabs
XTAL
1
30
PACTL / GPIO
NC
2
29
XOUT / GPIO
VCC
3
28
MISO / GPIO
NC
4
27
MOSI / SDAT
26
IRQ / GPIO
CYRF6936
WirelessUSB LP
40 lead QFN
NC
5
VBAT1
6
25
SCK
VCC
7
24
SS
VBAT2
8
23
NC
NC
9
22
NC
21
NC
* E-PAD Bottom Side
RFBIAS
10
20
NC
VCC
RESV
16
NC
19
15
NC
NC
14
RFN
18
13
GND
NC
12
RFP
In high-volume manufacturing, attention must be paid to all
aspects of reliability. Manufacturing a 0.47 µF, 0402 capacitor involves very thin dielectric construction. To achieve
maximum reliability, the capacitor must be handled and soldered in accordance with the manufacturers instructions. In
particular, be sure to observe the max. temperature during
IR reflow, and proper temperature ramp-up and ramp-down.
Failure to comply could result in intermittent capacitor
cracks, resulting in overall product failure.
17
11
A note about reliability:
Also, make sure the chosen capacitor has ample voltage
rating. A voltage derating factor of at least 2x is recommended for best reliability.
Where space allows, use of larger 0603 or 0805 capacitor
packages helps alleviate the capacitor reliability problem.
32
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Resets
Figure 3-2. CY4636 RDK Mouse v1.0 *B (PDC-9302-*C - 2xAA Batteries ~3.18V measured)
3.2.2
POR via Microcontroller
The user may choose to use a digital source instead of placing the capacitor for the POR event. On initial connection to
a power source, the external reset source must behave correctly to reset the radio in a similar fashion as having the
RST capacitor in place, otherwise correct startup behavior
and proper device functionality cannot be guaranteed.
There are some limitation to using a digital source for the
POR event. First, XOUT does not run during reset, so the
microcontroller cannot be solely clocked from XOUT. Secondly, the default state of the RST pin must be high.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
33
Resets
Figure 3-3. CY4636 RDK USB BRIDGE v1.0 *B (PDC-9263-*B)
3.3
Hard Reset
Although not necessary, the microcontroller can reset the
radio by driving the RST pin high and waiting long enough to
ensure that the RST pin voltage has exceeded 0.7 times the
VIO pin voltage. Then the microcontroller places the pin in a
high impedance state to allow the RST pin's internal 10K
ohm pull down resistor to bring the RST pin voltage back
down. Since the 10K ohm resistor and 0.47 µF capacitor,
form an R-C network, the voltage drop is not instantaneous.
After setting the GPIO pin in the high impedance state, the
microcontroller should use the register write until read successful polling method mentioned above to determine when
it is safe to begin radio initialization.
34
The data sheet (see Cypress Semiconductor Support on
page 9) states that the voltage on any input pin may not
exceed the voltage applied to the VIO pin (max VIO is 3.6 V).
However, higher voltages may drive the pins through series
resistors. The series resistors must limit current to less than
1 mA. Existing designs have done this using either 1K ohm
or 2.2K ohm resistors.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Resets
3.4
Soft Reset
As mentioned before, a hard microcontroller reset is not
necessary. After POR, the microcontroller can execute a
radio reset by setting the MODE_OVERRIDE_ADR.RST bit.
This is the method recommended to reset the microcontroller register and it should be part of the radio initialization
firmware. This does not satisfy the POR event requirements.
3.5
POR Event Power Cycling
Users can briefly power cycle the radio by uninstalling and
then quickly reinstalling batteries in keyboard/mouse/etc
applications.
In the above example, it is feasible that VBAT may not fall
below VIL which could in turn cause VRST to not rise above
VIH when the wrong size of RST capacitor is used.
Properly resizing the external RST capacitor (for example,
0.47 µF) value increases the probability that VRST rises
above VIH during VBAT ramp by increasing VRST time constant for all conditions. This assumes that VBAT ramps well
within the VRST time constant (less than 2 ms is recommended).
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
35
Resets
36
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
4. Interrupts
4.1
Introduction
The radio provides an interrupt (IRQ) output that is configurable to indicate the occurrence of different events. Using an
IRQ in a design eliminates latency caused by using a polling
loop technique. The radio features three sets of interrupts:
transmit, receive, and system interrupts. These interrupts all
share a single pin (IRQ), but can be independently enabled
or disabled. The contents of the enable registers are preserved when switching between transmit and receive
modes. This IRQ pin may be used by other device interrupts
in a system. These different interrupts must be appropriately
handled by an interrupt service routine appropriately.
4.2
Physical Layer
The IRQ pin (26) can be configured as an open drain output
or a standard CMOS output in register IO_CFG_ADR(0xD)
bit 7 (IRQ_OD). Clearing the IRQ_OD bit configures the IRQ
pin as a CMOS output, with the output ‘1’ drive voltage
being equal to VIO pin voltage. If higher voltages are
desired, than the IRQ_OD bit must be set and an external
pull up is needed. The polarity of the pin is also configurable
by setting or clearing IRQ_POL (bit 6) in the same register
set.
The IRQ pin can also be used as a GPIO pin by setting
IRQ_GPIO. When this bit is set, the IRQ function is multiplexed onto the MOSI pin. In this case the IRQ signal state
is presented on the MOSI pin whenever the SS signal is
inactive.
Note When using a CYRF69103/303 (PRoC), the user
must route the IRQ pin (27) to one of its GPIO pins.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
37
Interrupts
4.3
IRQ During POR
Figure 4-1. IRQ During POR (LP for Example)
When a “Power On” reset event occurs, the device is held in
“hard reset” via the reset pin (34) until VBAT reaches its VMIN
range. At this point, the reset pin deasserts and the system
is stable. The IRQ remains asserted after reset until the first
SPI clock cycle clears it. The IRQ pin is asserted again due
to a “soft reset” event that is issued to the device in order to
synchronize the internal SPI clock and is deasserted by the
next SPI clock cycle. IRQ remains deasserted but the polarity is changed to active high at the “IRQ Configured and
Ready” event by writing a value of 0x40 to the
IO_CFG_ADR (0x0D).
38
4.4
■
TX_IRQ_STATUS_ADR (0x04)
4.5
■
Transmit IRQs
Receiver IRQs
RX_IRQ_STATUS_ADR (0x07)
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Interrupts
4.6
Debouncing Non-Atomic
Radio Status Bits
Debouncing is needed when reading register 0x4
(TX_IRQ_STATUS_ADR)
and
register
0x7
(RX_IRQ_STATUS_ADR). If the first read of this returns
RXC IRQ = 1 and RXC ERR = 0, then firmware must execute a second read to this register to determine if an error
occurred by examining the status of RXE ERR. This is possible because this register can be written by the baseband
asynchronously, so a complete event might occur first and
then at a later time an error is detected and the bit is set. If
the first read of this register returns RXC IRQ = 1 and RXE
IRQ = 1, then the firmware must not execute a second read
of this register for a given transaction. Debouncing is very
important to ensure that the register is read correctly and the
baseband did not set the complete bit before setting the
error bit.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
39
Interrupts
4.7
4.7.1
IRQ Events
Successful Transactions
Figure 4-2. Successful Transactions (LP for Example)
40
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Interrupts
Successful transaction is when the transmitter (TX) and
receiver (RX) complete the transaction without any errors.
The status of the transaction can be determined by register
0x4
and
0x7,
TX_IRQ_STATUS_ADR
and
RX_IRQ_STATUS_ADR, respectively. The state of all IRQ
status bits in these two registers is valid regardless of
whether or not the IRQ is enabled in register 0x5
(RX_CTRL_ADR) and 0x2 (TX_CTRL_ADR). The IRQ output of the device is in its active state whenever one or more
bits in these registers is set and the corresponding IRQ
enable bit is also set. Status bits are no-atomic (different
flags may change value at different times in response to a
single event).
The values in these registers
TX_IRQ_STATUS_ADR
=
RX_IRQ_STATUS_ADR = 0x5A.
are as
0xBA
follows:
and
TX_CTRL_ADR = 0xBA: First three bits [2:0], transmit is
complete with no errors. Bit 1 is set signifying the IRQ has
triggered when transmission is complete. Reading this register clears this bit. TXC IRQ and TXE IRQ flags may change
value at different times in response to a single event. Due to
the fact that these bits can be set at different times, it is necessary to debounce the register, as explained in ?$paratext>? on page 39. This case is shown Figure 4-2 and is
marked as “Debounce.” Second three bits [5:3] indicate buffer status. Since all three bits are set in this capture, the buffer is empty. If an error occurred and all bytes were not
transferred, then these three bits would contain the status.
Bits [7:6] indicate system is stable and powered.
The TX IRQ fires once the packet is completely transmitted
and the ACK is received from the receiver. The IRQ is
cleared 22.83 µs when the status is read.
RX_CTRL_ADR=0x5A: First three bits [2:0], receive is complete with no errors. Bit 1 is set signifying the IRQ has triggered when receive is complete. Reading this register clears
this bit. This register is also debounced as shown in
Figure 4-2 due to the fact that these bits can be set at different times. Second three bits [5:3] indicate buffer status,
since it is 011 that means 8 - 15 bytes were received. Bits
[7:6] signify that start of packet was detected and received
buffer was not overwritten.
RX IRQ fires after the ACK is sent back to the transmitter
and is cleared once the status is read from register 0x7
(RX_IRQ_STATUS_ADR) after 22.33 µs.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
41
Interrupts
4.7.2
Unsuccessful Transaction: Out of Range
Figure 4-3. Unsuccessful Transaction: Out of Range
An unsuccessful transaction, as shown in Figure 4-3, shows
a failing transaction because the receiver was out of range.
TX_IRQ_STATUS_ADR = 0xBB: First three bits [2:0] show
transmit was complete but with error and no debounce
occurred. Bits [5:3] show 111 meaning the buffer is empty
and transmit has completed. The IRQ this time fires
because there is an error in transmitting and the ACK was
never received from the receiver. The IRQ is held for 22.67
µs and then cleared by reading the TX_IRQ_STATUS_ADR
register.
42
RX side has no activity because the receiver was out of
range. The receiver settings can be tuned to receive subsequent packets, by tuning LNA and ATT.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Interrupts
4.7.3
Unsuccessful Transaction: Buffer Error Due to Transmitting > 16 Bytes
Figure 4-4. Unsuccessful Transaction: Buffer Error Due to Transmitting > 16 Bytes(LP for Example)
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
43
Interrupts
The buffer size for the CYRF6936/6986 radio is 16 bytes. An
error occurs when more than 16 bytes of data is transferred.
Since the buffer size is 16 bytes, all data should be kept at
or below 16 bytes.
TX_IRQ_STATUS_ADR = 0x9F: First three bits [2:0] indicate that there was a buffer error and the transmit is complete. Bit 2 being set signifies that TX_BUFFER_ADR is
empty and the number of bytes remaining to be transmitted
is greater than zero. This is also evident in bits [5:3] indicating 011, meaning more than a 16 byte transfer was
attempted.
TX IRQ is shown in Figure 4-4. The IRQ fires because there
is an error in transmit and no ACK is received from the
receiver. This IRQ is cleared by reading the
TX_IRQ_STATUS_ADR register.
RX_IRQ_STATUS_ADR = 0x7D: The first three bits [2:0]
indicate that there was a buffer error and the receive did not
complete. Examining this register further, bits [5:3] indicate
the buffer is full. The buffer error interrupt bit is set because
the receiver buffer is full and more data was received. This
bit is cleared when RX GO is set and an SOP is received.
RX IRQ is shown in Figure 4-4 as well. This IRQ fires
because 16 bytes of data were received but there was a buffer error that caused the receive to not fully complete.
44
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Interrupts
4.7.4
Unsuccessful Read: Buffer Error - Reading From an Empty RX Buffer
Figure 4-5. Unsuccessful Read: Buffer Error - Reading From an Empty RX Buffer(LP for Example)
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
45
Interrupts
An unsuccessful read event can occur by attempting to read
data when the receive buffer is empty. Looking at the registers reveals the following:
RX_IRQ_STATUS_REG = 0x14: First three bits [2:0] reveal
a buffer error and transmit is not complete. This is apparent
in Figure 4-5. The FW does not clear this IRQ status bit,
therefore, the IRQ is held high. Bits [5:3] show that the buffer
is empty and bits [7:6] indicate no start of packet was
detected.
IRQ, in this case, was fired because the RXBERR IRQEN
bit was set in register RX_CTRL_ADR. Anytime a buffer
error occurs and this bit is set, the IRQ line asserts.
4.8
4.8.1
IRQ Sources
Transmit
4.8.2
Receive
4.8.2.1
RXE
4.8.2.2
RXC
4.8.2.3
RXBERR
4.8.2.4
RXB1
4.8.2.5
RXB8
4.8.2.6
RXB16
4.8.2.7
RX GO
4.8.2.8
RXOW
4.8.1.1
TXE
4.8.3
4.8.1.2
TXC
4.8.3.1
4.8.1.3
TXBERR
4.8.1.4
TXB0
4.8.1.5
TXB8
4.8.1.6
TXB15
4.9
4.8.1.7
TX CLR
4.9.1
Transmit
4.8.1.8
TX GO
4.9.2
Receive
4.8.4
4.8.4.1
4.9.2.1
Power
LVI(For WirelessUSB LP and PRoC
LP only)
Oscillator
Stable
Status
SOPDET
The SOPDET bug could be worked around independently of
RXB1. The SOPDET bug could be avoided by using the
RXB1, RXB8, etc., to imply that an SOP was detected (this
would not work on a zero-byte packet).
4.9.2.2
RXB1
The RXB1 bug could be worked around by reading the
RX_COUNT register after RXC/RXE and reading out the
remaining bytes left to be read. There are other workarounds as well.
4.10
46
Muxing IRQ Signal onto
MOSI
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
5. Crystal
5.1
Introduction
A properly designed WirelessUSB LP/LPstar system can
easily operate within a ten meter range. Carefully designed
WirelessUSB LP/LPstar systems can operate beyond this
ten meter range. There are many system design parameters
that can affect the range of your system. One of the most
important of these is a properly designed clock source.
5.2
Guidelines
Table 5-1. WirelessUSB LP/LPstar Crystal Requirements
Parameter
Value
Nominal Frequency
12 MHz
Operating Mode
Fundamental Mode
Resonance Mode
Parallel
Frequency Initial Stability
±30 ppm
Series Resistance
<60 ohms
Load Capacitance
10 pF
Drive Level
100 µW
This section discusses the following topics:
■
Clock and its frequency
5.2.1.2
■
PPM method of calculation
■
Load capacitance
■
Pullability and trim sensitivity
■
Crystal choice considerations
■
Clock frequency measurements
WirelessUSB LP/LPstar is designed to run with an input
clock frequency of 12 MHz. An input clock running at 5416
Hz off of 12 MHz produces an output RF that is off by 1
MHz, or one channel. WirelessUSB operates in systems
with both radio input clocks at 12005416 Hz, but its RF frequency is 1 MHz higher than expected.
■
Crystal layout
5.2.1.3
5.2.1
Clock
A good stable clock and its frequency are two of the most
important parts of a wireless system. If the radios in a wireless system are not operating on the same frequency they
cannot communicate with one another.
5.2.1.1
Clock Requirements
WirelessUSB LP/LPstar requires a clock frequency of 12
MHz. The output RF frequency ranges from 2.400 GHz to
2.480 GHz in 1 MHz increments (each channel is 1 MHz
apart). This output frequency is produced by using the input
clock as frequency reference for a VCO and PLL. The accuracy and stability of the input clock is dependent upon the
external crystal circuitry.
Clock Frequency
Clock Accuracy
As noted in Clock Frequency, WirelessUSB LP/LPstar can
operate with its input clock 5416 Hz off of 12 MHz. If it tries
to talk to another WirelessUSB LP/LPstar that has an input
clock of 12 MHz, and the two radios cannot communicate, it
is possible that the two radios are on two adjacent channels.
Even if the input clocks are 2700 Hz (225 PPM) apart they
are effectively using two different channels. WirelessUSB
LP/LPstar needs a more accurate input clock to effectively
communicate. WirelessUSB LP/LPstar needs to be paired
with another WirelessUSB LP/LPstar that has an input clock
within ±30 PPM of its own frequency for effective communication. A system using WirelessUSB LP/LPstar operates
with higher PPM difference, but performance decreases in
both range and interference immunity.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
47
Crystal
5.2.2
PPM
PPM is the abbreviation for ‘parts per million,’ a method of
calculation used to specify the permissible frequency deviation of a crystal or oscillator. One PPM on a 12 MHz clock is
12 Hz and 10 PPM is 120 Hz.
Total PPM clock accuracy is the sum of base PPM, temperature PPM, aging PPM, and trim sensitivity PPM. Total PPM
for a WirelessUSB LP/LPstar system should be less than
±30 PPM.
5.2.2.1
Base PPM
The base PPM is also known as the frequency tolerance of
the crystal being used. Frequency tolerance is the allowable
deviation from nominal frequency. Tolerance is usually
specified in ± PPM, at +25° C and a specific load capacitance. Typical tolerances are from ± 10 to 50 PPM.
5.2.2.2
Temperature PPM
Temperature PPM is also known as frequency stability. Frequency stability is the allowable deviation, in parts per million (PPM), over a specified temperature range. Deviation is
referenced to the measured frequency at +25° C. Typical
frequency stability numbers range from ±10 to 30 PPM.
Temperature PPM can be de-rated by de-rating the temperature range of the product.
5.2.2.3
Aging PPM
Aging is the change in the frequency of a quartz crystal unit
with the passage of time. A typical aging PPM is 2 PPM per
year. How aging PPM effects product reliability over time
needs to be taken into account during crystal selection.
5.2.3
Load Capacitance
Load Capacitance is the value of capacitance used in conjunction with the crystal unit in a parallel resonant oscillator
circuit. In a typical system the load capacitance of WirelessUSB LP/LPstar and printed circuit board (PCB) layout is 10
pF. Load capacitance of WirelessUSB LP/LPstar is typically
7 pF, but can vary 10% from radio to radio. Load capacitance also varies from one layout to the next and is dependent on signal routing, pad size, and layer stack up.
5.2.4
Pullability and Trim Sensitivity
Pullability is the change in crystal oscillator frequency due to
a change in the load capacitance. This is due to the change
in parallel resonant frequency when the load capacitance is
changed. Changing the frequency by changing the load
capacitance is referred to as ‘pulling’. The frequency can be
pulled in a parallel resonant circuit by changing the value of
load capacitance. A decrease in load capacitance causes an
increase in frequency, and an increase in load capacitance
causes a decrease in frequency.
48
Trim sensitivity is very closely related to pullability. In practical terms, the two are often interchangeable. Trim sensitivity
is a measure of the incremental fractional frequency change
for an incremental change in the value of load capacitance.
Trim sensitivity is expressed in terms of PPM/pF.
Typical trim sensitivities range from 5 to 30 PPM/pF.
5.2.5
Crystal Choice Considerations
When selecting a crystal, the easy choice is to pick a crystal
with low total PPM. Crystals with low total PPM can be
expensive, so some trade-offs can be made for lower cost
crystals. In a single system, all crystals used with WirelessUSB LP/LPstar should be the same type. Crystals of the
same type have similar frequency stability and aging characteristics. Since most systems will be in the same environment (especially HID systems) the temperature of the
system will be similar. Also, all parts of the system will be
built at approximately the same time. Using crystals of the
same type, therefore, reduces the effect of temperature and
aging PPM.
5.2.6
Clock Frequency Measurements
The WirelessUSB LP/LPstar radio clock frequency can be
measured with a frequency counter on the XOUT pin. Since
this signal is not used in most systems and the QFN package is difficult to probe, a PCB test point is recommended
for this signal. The clock output can be enabled with firmware by writing the XTAL_CTRL_ADR register in the WirelessUSB LP/LPstar radio. During normal operations, disable
this pin to remove it as a possible noise source on the PCB
and to reduce current consumption.
5.2.7
Crystal Layout
The ideal layout has the crystal on the same side of the PCB
as the radio and placed close to the crystal signal pins of the
radio with identical crystal trace lengths. This placement
keeps the crystal trace paths short and reduces parasitic
capacitances, which could produce noise in the system. The
two crystal traces should have matched length, avoid vias,
and have good isolation from noise sources. WirelessUSB
LP/LPstar’s crystal circuit performs best when the crystal
traces are closely matched in both lengths and parasitic
capacitances. In summary, the crystal layout is best if the
following conditions are met:
■
Crystal and radio are on same side of PCB
■
Crystal is placed near the crystal pin on the radio
■
Crystal trace paths are as short as possible
■
Match crystal trace paths for length and parasitic capacitance
■
Avoid vias on crystal traces
■
Isolate the crystal from noise sources
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Crystal
Crystal layouts should be identical for all radios in the system. By keeping layouts identical, the parasitic capacitance
on the crystal traces will be similar for each PCB in the system. Similar parasitic capacitance produce similar load
capacitance, thus reducing the effect of trim sensitivity PPM
on each radio of the system.
On multilayer PCB’s, one way of reducing parasitic capacitance on the crystal is to void the internal layers directly
beneath the crystal pads (see Figure 5-1 on page 49). This
is highly recommended when systems are comprised of
PCB’s with differing layer counts.
Figure 5-1. Crystal Layout
Internal GND Plane
Crystal and Radio
5.3
Typical Usage
Figure 5-2 shows the crystal circuit of LP. For LPstar, the circuit is similar as LP.
Figure 5-2. Crystal Circuit (LP for Example)
VBAT0
L/D
NC
VDD
RST
VIO
NC
NC
39
38
37
36
35
34
33
32
31
40
XTAL
1
12MHz
NC
VREG
Corner tabs
30
PACTL / GPIO
NC
2
29
XOUT / GPIO
V CC
3
28
MISO / GPIO
NC
4
27
MOSI / SDAT
26
IRQ / GPIO
CYRF6936
WirelessUSB LP
40 lead QFN
NC
5
V BAT1
6
25
SCK
V CC
7
24
SS
V BAT2
8
23
NC
NC
9
22
NC
21
NC
* E-PAD Bottom Side
RF BIAS
10
11
12
13
14
15
16
17
18
19
20
RFP
GND
RFN
NC
NC
VCC
NC
NC
RESV
NC
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
49
Crystal
5.3.1
Startup
Figure 5-5. Typical Wake Timing
Two methods of starting the crystal are the cold start (power
on reset) or the warm start (sleep/wake). Screen captures of
signals for both are presented in the following sections.
5.3.1.1
Cold Start (Power On Reset)
Figure 5-3. Typical Power On Reset Timing
5.4
5.3.1.2
Warm Start (Sleep/Wake)
Notes
VBAT (pin 38) is the power to the oscillator circuit. The
default state of XTAL pin is VBAT. The oscillator circuit can
handle VBAT input swings. The XTAL pin is driven to VBAT in
suspend AND during oscillator startup (POR, Wake, and
others). In normal operation mode, during the oscillator start
up sequence, the oscillator circuit drives the XTAL pin hard
to GND for 40 ns. A RST pin event gates XOUT.
To test sleep timing:
1. Write 20h to register 0Ch
2. Write A1h to register 0Fh
Figure 5-4. Typical Sleep Timing
To test wake timing:
1. Write 20h to register 0Ch
2. Write A1h to register 0Fh
3. Write A5h to register 0Fh
50
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
6. Power Management Unit
6.1
Introduction
The WirelessUSB LP’s Power Management Unit (PMU)
requires a single supply: 1.8V to 3.6V derived directly from
an external battery voltage source or other external power
supply connected to the VBAT pins.
The user can configure the LP’s PMU output voltage (VREG)
to several minimum values between 2.4V and 2.7V. VREG
provides up to 15 mA average load to external devices. It is
possible to disable the PMU, and to provide an externally
regulated DC supply voltage to the device’s main supply in
the range 2.4V to 3.6V. The PMU also provides a regulated
1.8V supply to internal logic. The PMU provides high boost
efficiency (74–85% depending on input voltage, output voltage, and load) when using a Schottky diode and power
inductor. This eliminates the need for an external boost converter in many systems where other components require a
boosted voltage. However, the user achieves reasonable
efficiencies (69–82% depending on input voltage, output
voltage, and load) when using low cost components such as
SOT23 diodes and 0805 inductors. The PMU also provides
a configurable low battery detection function, which is read
over the SPI interface. The user selects one of seven
thresholds between 1.8V and 2.7V. The interrupt pin is configured to assert when the voltage on the VBAT pins falls
below the configured threshold. The low voltage IRQ signal
is not a latched event. When the device is in sleep mode,
the device disables battery monitoring.
Unlike a traditional DC to DC boost converter, when the
input voltage is at or above the desire output voltage, there
is a FET inside the part that connects from VBAT to VREG.
This has an important advantage, in that with a traditional
DC to DC boost, if VBAT < (VREG + diode drop) the boost is
switching; with the LP’s PMU this is not the case, and
switching does not start until VBAT < VREG. For more
details, see Figure 6-1 on page 53.
If VBAT > VREG (for example, VBAT = 3.3V) then VREG =
VBAT. VREG is only at its configured voltage (2.4, 2.5, 2.6, or
2.7V) when VBAT < VREG. An important point to note is that
the configured VREG value is a guaranteed minimum, not a
nominal. Thus, typically the voltage on VREG with VREG set
to 2.7V and VBAT = (for example) 1.8V varies between
2.73V and 2.78V. This is important, because it means that
you can set the VREG configured voltage to equal the VCC
(min) voltage of any chip that the PMU is powering.
Unlike LP, LPstar’s PMU doesn’t support boost or low battery detect function. For more details in their differences,
please refer to the application note AN68105 Migration of
WirelessUSB™ LP Designs to WirelessUSB™ LPstar.
6.1.1
Functional Description
The LP’s PMU contains a linear low drop out regulator tied
directly to the VBAT (battery) pins. This regulator supplies the
radio’s digital logic with at least 1.8V when VBAT is in the
range of 1.9V to 3.6V and gracefully transitions to tracking
VBAT when below 1.9V (that is, the digital logic voltage
droops down to as low as 1.7V when VBAT is at 1.8V). The
regulator transitions to sleep mode with a controlled rise
time up to the external VBAT voltage. It also transitions back
to the regulated voltage with a similarly controlled fall time.
The regulator is stable with an external 0.47 µF bypass
capacitor for no load up to the maximum load current.
The LP’s PMU contains a switching regulator-block based
on classic, industry standard, boost mode, inductor-diode
based, switching regulators. The switching regulator
requires an external power inductor (tolerance ±20%) and
diode (high current Schottky diode or switching diode),
which adds cost. But, this cost is offset by the fact that the
on-chip regulator alleviates the need for the designer to provide one externally; it supports up to 15 mA of additional
load current to other devices. Efficiency is over 80% at high
load current. It uses only two external, inexpensive electrolytic capacitors (tolerance -20% to +80% over the 0–70C
temperature range). Performance depends on external component selection and PCB layout.
When PMU EN = 1
■
When PMU OUTV = 00: The PMU output equals the battery voltage from 2.7V to 3.6V. It holds the output at 2.7V
minimum for battery voltages from 1.8V to 2.7V through
an active inductor-diode charge pump circuit connected
to the L/D pin.
■
When PMU OUTV = 01: The PMU output equals the battery voltage from 2.6V to 3.6V. It holds the output at 2.6V
minimum for battery voltages from 1.8V to 2.6V through
an active inductor-diode charge pump circuit connected
to the L/D pin.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
51
Power Management Unit
■
■
When PMU OUTV = 10: The PMU output equals the battery voltage from 2.5V to 3.6V. It holds the output at 2.5V
minimum for battery voltages from 1.8V to 2.5V through
an active inductor-diode charge pump circuit connected
to the L/D pin.
diode used in a wireless mouse application.
details, see Figure 6-1 on page 53.
For more
LPstar does not have a pin of VREG. For more details please
refer to LPstar datasheet.
When PMU OUTV = 11: The PMU output equals the battery voltage from 2.4V to 3.6V. It holds the output at 2.4V
minimum for battery voltages from 1.8V to 2.4V through
an active inductor-diode charge pump circuit connected
to the L/D pin.
When PMU EN = 0
■
The user disables the PMU (through SPI write) to allow
direct drive from an external 2.4V to 3.6V voltage source
(such as, USB connection through a linear 3.3V regulator). See the PWR_CTRL_ADR bit 7 (PMU Enable)
descriptions in the 38-16015 data sheet for more
details. See Cypress Semiconductor Support on page 9.
■
The user disables the PMU (through SPI write) to allow
an external boost voltage regulator to take over control
of the VREG voltage. See PWR_CTRL_ADR bit 7 (PMU
Enable) descriptions in the 38-16015 data sheet for
more details.
For LP , VREG tracks the battery until the battery voltage falls
below the VREG programmed threshold (2.4, 2.5, 2.6, or
2.7V VREG = 2.7V is the default). At voltages below the
VREG threshold, the PMU's switching regulator turns ON and
holds the VREG voltage to be no less than the threshold
value for VREG load current from 0 to 30 mA. The VREG voltage then, is a saw tooth waveform that is approximately 10
Hz to 110 KHz with ripple of 20 mVpp to 110 mVpp. This
depends on the VREG load current and the VBAT voltage; it
potentially is from 1.7V to the VREG programmed threshold.
The rise slope of the sawtooth is nearly constant but the
amplitude is a function of VBAT. The fall slope is VREG load
current dependant. The minimum voltage of the sawtooth
waveform is greater than or equal to the VREG programmed
threshold over the VREG load current range of 0 to 30 mA.
This includes the 0–15 mA of external load current allowed
by the user for powering a microcontroller, optical diode, or
both.
For LP , the VREG output tracks the battery voltage when the
VBAT voltage is above the programmed threshold through a
PFET switch that connects VBAT to VREG when VBAT > VREG
threshold. A voltage regulator charge pump automatically
turns on when the battery voltage drops below the programmed threshold. The threshold is programmable for
2.4V, 2.5V, 2.6V, and 2.7V to accommodate currently available microcontrollers and optical diodes. The VREG output
supplies power for much of the radio chip circuitry (up to
15 mA) and can supply an additional 15 mA to power external devices such as a low power microcontroller and optical
52
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Power Management Unit
Figure 6-1. Typical VBAT vs. VCC Behavior
.
The LP’s PMU contains a low voltage monitoring and indication circuit (LVI) that has a programmable trip voltage of
(1.8V, 2.0V, 2.2V, and VREG) where VREG is the programmed regulated voltage setting (2.4V, 2.5V, 2.6V, or
2.7V). Use the LVI VREG settings to inform the microcontroller of the switching regulator onset. You can also use the
LVI as a seven-level battery capacity indicator.
The PMU supply current in sleep mode is approximately
50 µA (nominal) when supplying VREG leakage load current.
See the PWR_CTRL_ADR bit 5 (PMU Sleep Mode Enable)
descriptions in the 38-16015 data sheet for more details.
Note If you use an external supply for VBAT, make certain it
is of the ‘linear’ regulator type that can deliver at least a 0.5A
current (remember, the switching regulator's inductor has a
peak charge current of up to 400 mA).
6.1.2
Power Supply Choices
There are two common ways of powering VBAT.
1. Use two AAA alkaline batteries or similar (coin-cell, and
others). See Figure 6-2 on page 54.
2. Use a low noise LDO linear regulator. See Figure 6-3 on
page 55.
The PMU disabled mode current is approximately 0.1 µA.
See the PWR_CTRL_ADR bit 7 (PMU Enable) descriptions
in the 38-16015 data sheet for more details.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
53
Power Management Unit
6.1.2.1
Battery Configuration
If you use batteries, make certain to connect the battery to VBAT. This method requires the use of an inductor, diode, and
capacitors. The LP’s PMU generates VREG. It also generates the 1.8V for the core.
Unlike LP, LPstar does not support the boost functionality and hence in the below figure, the circuit consisting of the L/D pin,
L3 and D1 is applicable for only LP. And the VBAT and VCC should be both from 2.7 V to 3.6 V.
Figure 6-2. Typical Battery Application Circuit for LP
1.5V
AAA
Alkaline
C19
100µ F
6.3V
NOTES:
1. C19, protects against
momentary lose of batteries
AND slightly increases battery
life
Traces can
see 2A for
200us
20mil
1/10th ohm
total for
this trace
1.5V
AAA
Alkaline
+
1.8V to
3.6V
2. Apply pin 6 filtering
Vcc
L3
10µH
3. Apply pin 38 filtering
4. Notch inner layers for 4layer (or more) boards around
crystal and RF components
traces and pads
2.4V to 3.6V
1 XTAL
PACTL 30
2 NC
XOUT 29
3 VCC
MISO 28
4 NC
MOSI 27
5 NC
CYRF6936
WirelessUSBTM LP
6 VBAT
IRQ 26
SCK 25
7 VCC
SS 24
8 VBAT
NC 23
9 NC
NC 22
E-PAD BOTTOM SIDE
NC 21
NC 20
NC 18
NC 17
NC 15
VCC 16
NC 14
RFN 13
RFP 11
GND 12
The 100 µF capacitor (C19) primarily supports the supply
during temporary battery disconnection during physical
shock (for example, banging or dropping). Place the 100 µF
capacitor close to the battery terminals between the power
connector to the PCB and the supply line or plane that feed
VBAT to the radio. This effectively bypasses the inductance
of the battery and power supply leads which sometimes are
very long (a few inches or so). Keep the resistance of the
VBAT supply line between 100 µF capacitor and the radio
very low (milliohms) to ensure no extra droop voltage occurs
when the switching regulator is running. For a four layer
board where VBAT is an internal plane, you can place the
100 µF capacitor anywhere since the resistance of the plane
RESV 19
10 RFBIAS
54
400mA while
boosting
10 mil, 50m ohm
max, 0.6 ohm
internal
31 NC
32 NC
33 VIO
34 RST
35 VDD
36 NC
37 L/D
38 VBAT
39 NC
CORNER
TABS
40 VREG
5. Keep L/D trace lengths as
short as possible, don't run
this trace through module
header, etc.
C12
10µF
6.3V
D1
BAT400D
is extremely low. But, for two layer boards where VBAT is a
trace, make certain that the trace is wide between the power
connector and capacitor and between the capacitor and the
radio so that the overall resistance is in the milliohm range.
The output impedance of near dead batteries is around 1–2
ohms which causes a lot of ripple when the switching regulator is running due to the 400 mA peak inductor charging current. You do not want the layout parasitic resistance to add
to the battery resistance; that way you can take out all the
energy from the battery that is possible before the system
dies. Keep the battery wire resistance very low as well, so
that only the battery internal resistance is the limiting factor.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Power Management Unit
6.1.3
Fixed Value Inductor and
Capacitor
Inductor saturation can be observed with an oscilloscope,
monitoring voltage at the L/D pin. During the switch-ON
conduction cycle, voltage should be small, equal to the IR
drop of Rds of the internal FET switch, multiplied by the linearly increasing inductor current. If saturation occurs, however, the current increase is no longer linear, but a fast
exponential rise. This would indicate a poor inductor selection.
By the LP design, the values of the inductor and VREG
capacitor are fixed at 10 µH and 10 µF, respectively.
6.1.3.1
Selecting a Suitable Inductor
The Taiyo Yuden CB2012T100MR reference example part
specification limit for 1 mS current pulse 1% duty cycle is
2.6 amps. The Taiyo Yuden inductor is only recommended
for minimal loads (radio + MCU only, no additional loads).
For external loads use a Sumida Part # CDH53100LC
inductor or similar.
6.1.3.2
Low-Noise LDO Linear Regulator
Configuration
In this configuration for LP, VBAT, VCC, and VREG are all tied
to the output of a low noise LDO. The PMU boost function is
not used. The inductor and diode are not used. L/D pin is
connected to ground. The only PMU function is the 1.8V
regulator for the core.
In boost regulators such as this, inductor saturation during
current ramp-up must be avoided. Most good quality inductors will not show this problem. Inductors that are too small,
or poor quality, will go into saturation, thus limiting their ability to store enough energy during the switch-ON conduction
cycle, and may not produce enough DC output power. This
problem is noticeable at low battery voltage.
For LPstar, the configuration is similar to LP except the LDO
output must be from 2.7 V to 3.6 V.
Figure 6-3. Typical Linear Regulator Application Circuit for LP
NOTES:
1. Place C21
close to radio
VIN
Low-Noise
LDO
C20
10 µF
2. Add C22, when
C21 not placed
close to radio
C21
10 µ F
6.3V
2.4V to 3.6V (PMU OFF)
1 XTAL
31 NC
32 NC
33 VIO
34 RST
35
VDD
36 NC
37 L/D
38 VBAT
39 NC
CORNER
TABS
40 VREG
C22
10 µF
6.3V
(0805)
PACTL 30
2 NC
XOUT 29
3 VCC
MISO 28
4 NC
MOSI 27
5 NC
CYRF6936
WirelessUSBTM LP
6 VBAT
IRQ 26
SCK 25
7 VCC
SS 24
8 VBAT
NC 23
9 NC
NC 22
E-PAD BOTTOM SIDE
NC 21
NC 20
NC 18
NC 17
NC 15
VCC 16
NC 14
RFN 13
RFP 11
GND 12
RESV 19
10 RFBIAS
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
55
Power Management Unit
6.1.4
Filtering Power Supply Noise
When VBAT range 2.0V < > 3.6V (example, CR2032):
As previously mentioned, the analog RF performance of the
radio is significantly degraded by power supply noise. Apply
the following filtering rules for the following VBAT conditions.
■
Pin 6 (VBAT1)–shunt capacitor C = 0.047 µF
■
Pin 38 (VBAT0)–shunt capacitor C = 10 µF,
series resistor R = 1 ohm
When VBAT range 1.8V < > 3.6V (example 2 x AAA):
When VBAT range 2.4V < > 3.6V (example, Linear LDO):
■
Pin 6 (VBAT1)–shunt capacitor C = 1 µF,
series resistor R = 47 ohms
■
Pin 6 (VBAT1)–shunt capacitor C = 0.047 µF
■
Pin 38 (VBAT0)–shunt capacitor C = 0.047 µF
■
Pin 38 (VBAT0)–shunt capacitor C = 10 µF,
series resistor R = 1 ohm
For more details, see Figure 6-4 on page 56.
Figure 6-4. Typical Power Supply Filtering Options for LP
NOTES:
VAAA(2)
VAAA(2)
1. When not using
PMU you may
remove R2, and
replace C7 with
0.047µF 6.3V
R2
1 Ohm
1%
R1
47 Ohm
C8
1µF
6.3V
(0402)
C7
10µF
6.3V
(0805)
C16
C15
GPIO / PACTL 30
2 NC
C11
31 NC
1 XTAL
32 NC
33 VIO
34 RST
35 VDD
36 NC
37 L/D
38 VBAT
39 NC
40 VREG
CORNER
TABS
C5
GPIO / XOUT 29
3 VCC
GPIO / MISO 28
4 NC
SDAT / MOSI 27
5 NC
CYRF6936
WirelessUSBTM LP
6 VBAT
GPIO / IRQ 26
SCK 25
C9
7 VCC
SS 24
C13
8 VBAT
NC 23
9 NC
NC 22
E-PAD BOTTOM SIDE
NC 21
NC 20
NC 18
NC 17
NC 15
VCC 16
NC 14
RFN 13
RFP 11
GND 12
RESV 19
10 RFBIAS
C10
0.47 µF 6.3V – C5
0.047 µF 6.3V – C9, C10, C11, C13, C15, C16
6.1.5
Switching Regulator Frequency
The steady state frequency of the switching regulator varies
with load current and can range from 10 Hz (no load in sleep
mode) and 110 KHz when delivering maximum current at
VBAT = 1.8V. The start up oscillator, which only runs when
the part is first connected to a supply, runs at about
250 KHz.
56
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Power Management Unit
6.2
Sleep Mode
To shut down the device to a fully static sleep mode, write to
the FRC_END = 1 and END_STATE = 000 bits in the
XACT_CFG_ADR register over the SPI interface. The
device enters sleep mode within approximately 35 µs after
the SPI/SS signal goes high at the end of this SPI transaction.
Note The time to enter sleep mode is largely set by the VDD
supply decoupling capacitor (0.47 µF) charging up to VBAT
in sleep mode. Once VDD = VBAT, the sleep mode current
settles down to its minimum value. The maximum time
occurs when VBAT = 3.6V
6.2.1
Wake from Sleep Response Time
The wake from sleep response time is crystal dependent,
but typically less than 1 ms.
In addition, the radio has an oscillator stable interrupt that
when enabled, is driven onto the IRQ pin.
Note The MCU talks to the radio's digital block with clocks
turned OFF.
6.3
LVI IRQ
LVI IRQ is an active level interrupt for LP and PRoC LP only.
If the low voltage detect is enabled as an IRQ, it is passed
from the internal analog signal straight to the IRQ pin. Reading the status does not clear an event, it reflects the status
all the time. LVI is automatically disabled when the device is
in sleep mode, otherwise it is active.
Applications that want to use the LVI feature to monitor the
battery voltage, must enable the PMU during LVI sampling.
6.3.1
Implementing Low Voltage
Monitoring
Figure 6-5 on page 58 shows one example of how you can
make a crude battery monitoring ADC using the LVI IRQ.
Note Do not monitor the battery voltage while actively transmitting or receiving, as higher Icc affects the measurement.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
57
Power Management Unit
Figure 6-5. Battery Monitoring Example
test_hi:
battery_
protection
Start
Radio Sleep +
VREG = 2.7V
LVI = PMU
Voltage
Set MCU for 1sec
IRQ
End state = idle +
force end state
LVI = 1
Disable all other
MCU IRQs
Set LVI = 2.2V
VBAT > 2.7
ABORT
Yes
VBAT > 2.6
PMU = 2.7V
ABORT
Yes
VBAT > 2.5
PMU = 2.7V
ABORT
No
MCU = Sleep Mode
LVI = 1
Yes
Yes
LVI = PMU = 2.6V
GOTO
test_hi
No
LVI = 1
ABORT
Set LVI = 2.0V
No
LVI = 1
Yes
VBAT > 2.0
ABORT
End State =
Sleep + Force End
State
LVI = PMU = 2.5V
No
LVI = 1
Set LVI = 1.8V
No
LVI = 1
Yes
VBAT > 1.8
ABORT
LVI = PMU = 2.4V
No
1sec IRQ
GOTO
battery_protection
LVI = 1
End state = Idle +
force end state
Yes
VBAT > 2.4
No
PMU = 2.7V
Read LVI IRQ
Loop > 20x
End state = sleep +
force end state
LVI = 1
20x in a
row
Yes
VBAT > 1.8
return to
Main
Processing
Loop
No
GOTO
battery_protection
58
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
7. Digital Baseband
7.1
Introduction
The baseband consists of numerous sub-blocks. At a high level, it serves as the interface between the SPI block data buffers
and the radio analog front end. The primary sub-blocks that are discussed in this section are the modem and framer. The
modem manages the DSSS encoding and decoding of the data stream; the framer is responsible for start of packet generation and reception, CRC16 generation and checking, and also end of packet detection and length field management.
The baseband also provides control and interface to the clock and the power management unit. Those functions are discussed in separate chapters.
Figure 7-1. Baseband Simplified Block Diagram
IRQ
MISO
MOSI
nSS
SCLK
Serial Peripheral Interface
Interrupt
Controller
Data buffers
TX Ctrl
Modem
TX Modem
RX Modem
TX Ctrl
Data
TX Ctrl
Data
Clock and Reset Control
Flags
RX Framer
Data
TX Ctrl
Reset
Write
TX Framer
Data
Clock
Data
Reset
Flags
Read
Data
Clock
Baseband
Framer
Clock
Reset
Radio
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
59
Digital Baseband
There are multiple data rates available in the WirelessUSB
LP family. For DSSS modes, the user’s data is encoded in a
series of chips, based on the configuration register settings.
In raw GFSK mode the chips transmitted over the air are
equivalent to the user’s data. Regardless of the user
selected data rate, the rate that information is actually transferred over the air (the chip rate) is always 1 Mbps. Different
DSSS data rates are achieved by encoding a different number of bytes in each symbol.
When in receive mode with packet framing enabled, the
device is always ready to receive data transmitted at any of
the supported bit rates. This enables the implementation of
mixed-mode systems in which different devices use different
data rates. This also enables the implementation of dynamic
data rate systems that use high data rates at shorter distances or in a low-moderate interference environments, and
change to lower data rates at longer distances or in high
interference environments.
7.2
Modem
modes a single transmission of a PN code equates to one
symbol. Each symbol corresponds to a different number of
data bits depending upon the data mode.
For the DSSS mode, a single 16 byte (128 bit) file register is
used for storing the code: DATA_CODE_ADR file register
0x23. The value in this register is:
0x02F9939702FA5CE3012BF1DB0132BE6F
Do not change this value. All WirelessUSB LP family systems in all applications can use this code. Separate start of
packet PN codes, discussed in the section Start of Packet
on page 63, are used to co-locate different systems.
This register is broken up in different ways to accommodate
the different data modes. The contents meet the requirements of our standard PN codes for good auto correlation
and cross correlation. They also meet the requirements of
multiplicative codes, meaning that its sub-sections can be
used for both 32-chip and 64-chip codes that also have good
auto correlation and cross correlation properties on their
own.
The modem implements the coding layer that converts the
stream of data in the data buffers to sequences of chips. It
works with the framer to provide start of packet markers and
other structures necessary to packetize the data. The
modem also decodes received data, using a correlator function to center and decode the chip sequence.
7.2.1
Various data modes are supported by the modem, configured by register settings. These modes, in conjunction with
a user specified 32 or 64 chip PN code, implement a variety
of data rates. Data mode is set with bits 4:3, DATA MODE,
of TX_CFG_ADR register 0x03. The length of the data PN
code is set with bit 5, DATA CODE LENGTH. Data modes
and data rates are listed in the following table.
Some things to note when using GFSK mode:
Table 7-1. Data Modes and Data Rates
Data Mode
Gaussian
Frequency
Shift Key
Eight x Data
Rate(64chip for
LP only)
Double Data
Rate(for LP only)
Single Data
Rate(for LP only)
Abbreviation
Data Mode
Bit Settings
Data Code
Length
Bit Setting
Data Rate
GFSK
00
N/A
1 Mbps
0 (32 chips/bit)
250 Kbps
8DR
DDR
SDR
01
1 (64 chips/bit)
125 Kbps
0 (32 chips/bit)
62.5 Kbps
1 (64 chips/bit)
31.25 Kbps
10
0 (32 chips/bit)
31.25 Kbps
1 (64 chips/bit)
16.125 Kbps
Gaussian Frequency Shift Key (GFSK) mode is the fastest
data rate, however care must be taken in its use. By definition, this mode eliminates the advantages of DSSS technology making it much more susceptible to errors.
A start of packet is required as discussed in the section
Framer on page 63. The SOP is PN code encoded data,
thus detection of a start of packet is as reliable for GFSK as
it is for other modes.
The length field is also required, but is not encoded data.
Therefore, the probability of this field being in error is much
higher with GFSK packets. An error in this field results in
erroneously truncated data or excess random data. An erroneously long length field also ties up the correlator for the
amount of time required to receive a packet of the erroneous
length.
The data is not encoded, therefore any chip error results
directly in a data bit error. This makes the entire packet more
susceptible to errors.
Only slow channels are supported. Bit 0, ALL SLOW, of
ANALOG_CTRL_ADR register 0x39 should be set in order
to make use of the full range of channels.
11
The first mode, raw GFSK, does not use DSSS encoding of
the data. Therefore each chip sent across the air during the
data phase is directly equivalent to 1 bit of user data. The
data rate is 1 Mbps. As shown, the remaining three modes
can be used with either 64 or 32-chip data PN codes resulting in two possible data rates for each mode. In the DSSS
60
Gaussian Frequency Shift Key
7.2.2
Eight x Data Rate
Eight x Data Rate (8DR) is the most robust mode of the
WirelessUSB LP family of devices. The radio was designed
around this operating mode and certain functions enable it
to more accurately center on bits and correctly decode the
chip stream. This has been determined in practice through
in-chamber characterization and outdoor range testing.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Digital Baseband
There is generally little need for the DDR and SDR modes
except in cases where backward compatibly is required;
they generally provide slower performance and increased
power consumption. There may be situations where the
GFSK mode provides some advantages, buts its use has to
be balanced against the less reliable transmission of data.
In 8DR mode, each symbol represents eight bits of user
data. The 32-chip codes are used for 250 Kbps rate and 64chip codes are used for 125 Kbps rate. In this proprietary
mode, 128 derivative PN codes are generated based upon
the organization of the contents of the DATA_CODE_ADR
file register 0x23. These 128 codes plus the state of the
code (normal or inverted) are used to represent the eight
bits of data.
7.2.3
Double Data Rate
Double Data Rate (DDR) mode works in a fashion similar to
the older WirelessUSB LS and LR devices. In DDR, each
symbol represents two bits of data. Two PN codes are used,
derived from the data stored in DATA_CODE_ADR file register 0x23, as shown in 7-2
Table 7-2. DDR Data PN Code Configuration
DATA_CODE_ADR File Register 0x23
Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 6 Byte 5 Byte 4 Byte 3 Byte 2 Byte 1 Byte 0
64-Chip DDR
32-Chip DDR
Data PN Code 1
Not Used
Data PN Code 0
Data PN Code 1
Not Used
Data PN Code 0
These two codes and their two states, normal and inverted, allow the encoding of two bits of data.
Table 7-3. DDR Symbol Encoding
Symbol
Transmitted Code
00
Data PN code 0
01
Data PN code 0
10
Data PN code 1
11
Data PN code 1
7.2.4
Single Data Rate
Single Data Rate (SDR) is the simplest encoding scheme. A single PN code is required. Each symbol represents a single bit
of user data. The data PN code is transmitted in its normal state to represent a ’1’ and inverted to represent a ‘0’.
Table 7-4. SDR Data PN Code Configuration
DATA_CODE_ADR File Register 0x23
Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 0 Byte 6 Byte 5 Byte 4 Byte 3 Byte 2 Byte 1 Byte 0
64-Chip DDR
32-Chip DDR
7.3
Not Used
Not Used
Data PN Code
Not Used
Backward Compatibility
The CYRF6936 IC is fully interoperable with the main
modes of the first generation devices, namely the
CYWUSB6934-LS and CYWUSB6935-LR devices. The
62.5 kbps mode is supported by selecting 32 chip DDR
mode. Similarly, the 15.675 kbps mode is supported by
selecting 64 chip SDR mode.
In this way, a suitably configured CYRF6936 IC device may
transmit data to or receive data from a first generation
device, or both. Backward compatibility requires disabling
the SOP, length, and CRC16 fields.
Not Used
Data PN Code
radio.There are two possible modes: SDR mode and DDR
mode (8-DR and GFSK modes are not present in the first
generation radio). The second generation radio must be initialized using the RadioInitAPI of the LP radio driver and
then the following register bits need to be configured to the
given byte values. Essentially, the following deactivates the
added features of the second generation radio and takes it
down to the level of the first generation radio; the data format, data rates, and the PN codes used are recognizable by
the first generation radio.
Shown in Table 7-5 and Table 7-6 are the different configurations of the registers and firmware that enable a second
generation radio to communicate with a first generation
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
61
Digital Baseband
Table 7-5. DDR Mode
Register
Value
Description
TX_CFG_ADR
0X16
32 Chip PN Code, DDR, PA = 6.
RX_CFG_ADR
0X4B
AGC is enabled. LNA and attenuator are disabled. Fast turnaround is disabled, the device
uses high side receive injection, and Hi-Lo is disabled. Overwrite to receive buffer is enabled
and the RX buffer is configured to receive 8 bytes maximum.
XACT_CFG_ADR
0X05
AutoACK is disabled. Forcing END STATE is disabled. The device is configured to transition
to Idle mode after a receive or transmit. ACK timeout is set to 128 µs.
FRAMING_CFG_ADR
0X00
All SOP and framing features are disabled. Disable LEN_EN=0 if EOP is needed.
TX_OVERRIDE_ADR
0X04
Disable Transmit CRC-16.
RX_OVERRIDE_ADR
0X14
The receiver rejects packets with a zero seed. The RX CRC-16 Checker is disabled and the
receiver accepts bad packets that do not match the seed in CRC_Seed registers. Basically,
this helps in communication with the first generation radio that does not have CRC capabilities.
ANALOG_CTRL_ADR
0X01
Set ALL SLOW. When set, the synthesizer settle time for all channels is the same as the slow
channels in the first generation radio.
DATA32_THOLD_ADR
0X03
Sets the number of allowed corrupted bits to 3.
EOP_CTRL_ADR
0x01
Sets the number of consecutive symbols for noncorrelation to detect end of packet.
PREAMBLE_ADR
0xAAAA05
AAAA are the 2 preamble bytes. Any other byte can also be written into the Preamble register
file. Recommended counts of the preamble bytes to be sent should be >4.
Table 7-6. SDR Mode
Register
Value
Description
TX_CFG_ADR
0X3E
64 Chip PN Code, SDR Mode, PA = 6.
RX_CFG_ADR
0X4B
AGC is enabled. LNA and attenuator are disabled. Fast turnaround is disabled, the device
uses high side receive injection, and Hi-Lo is disabled. Overwrite to receive buffer is enabled
and RX buffer is configured to receive 8 bytes maximum. Enables RXOW to allow new packets to be loaded into the receive buffer. This also enables the VALID bit, which is used by the
first generation radio’s error correction firmware.
XACT_CFG_ADR
0X05
AutoACK is disabled. Forcing END STATE is disabled. The device is configured to transition
to Idle mode after receive or transmit. ACK timeout is set to 128 µs.
FRAMING_CFG_ADR
0X00
All SOP and framing features are disabled. Disable LEN_EN=0 if EOP is needed.
TX_OVERRIDE_ADR
0X04
Disable Transmit CRC-16.
RX_OVERRIDE_ADR
0X14
The receiver rejects packets with a zero seed. The RX CRC-16 checker is disabled and the
receiver accepts bad packets that do not match the seed in the CRC_seed registers. Basically, this helps in communication with the first generation radio that does not have CRC
capabilities.
ANALOG_CTRL_ADR
0X01
Set ALL SLOW. When set, the synthesizer settle time for all channels is the same as the slow
channels in the first generation radio for manual ACK consistency.
DATA64_THOLD_ADR
0X07
Sets the number of allowed corrupted bits to 7, which is close to the recommended 12%
value.
EOP_CTRL_ADR
0xA1
PREAMBLE_ADR
0xAAAA09
62
Sets the number of consecutive symbols for noncorrelation to detect end of packet.
AAAA are the 2 preamble bytes. Any other byte can also be written into the Preamble register
file. Recommended counts of the preamble bytes to be sent should be >8.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Digital Baseband
7.4
Framer
The framer block consists of two core state machines, one
for the transmit path and the other for the receive path, each
running at 12 MHz. Packetized WirelessUSB data has a
number of sub-components. The framer is actually not
responsible for all of them. The modem block manages the
preamble and start of packet symbols; however, all of the
packet structures are covered here for simplicity.
7.4.1
Packet Structure
Data packet and ACK packet structures are shown below.
Figure 7-2. Packet Structures
Preamble
Data packet structure
SOP
LEN
DATA
CRC
cant effect on the ability to receive a packet. Without the
preamble sequence to allow the receive correlator an opportunity to synch on the data stream, it is much more likely for
the receiver to fail to correlate on the SOP symbols in the
case of framed data, or on the data itself in the case of
unframed modes. Failing to correlate on a SOP means that
no data packet will be received. For unframed modes, the
result can be corrupted data.
The second and third bytes of the file register set the least
significant eight chips and most significant eight chips of the
preamble sequence respectively.
Note that when reading or writing this register, all three
bytes must be read or written. Failing to do so means that
the contents will be shifted by the number of reads or writes.
A subsequent access will then not start with the first byte.
The default value of this register, 0x333302, is the recommended preamble sequence.
Figure 7-3. Default, Recommended Preamble Sequence
Preamble
ACK packet structure
SOP
CRC
The darker gray areas are those handled by the modem
block. The lighter gray areas are handled by the framer. The
white regions are the user’s data going to or coming from
the data buffers. All of the packet sub-components can be
disabled, but some are required in order to make use of certain data modes, and other fields, such as preamble, should
be used to ensure the robustness of the wireless link.
The preamble, SOP, length, and CRC values are not stored
or transmitted from the buffer memory. The TX framer and
modem insert these values based on register settings and
the RX framer and modem extract them from the incoming
packet.
7.4.1.1
Preamble
The preamble is a 16-chip sequence transmitted at the start
of a packet. Its primary purpose is to allow the receive correlator to establish the appropriate bit centering and synch up
on the data stream before the other structures in the packet
are transmitted.
The preamble pattern and length are set through the
PREAMBLE_ADR file register 0x24. Byte 1 of the file register establishes the number of repetitions of the 16-chip
sequence. The preamble may be disabled by writing 0x00 to
this byte, but it is highly advised to make use of the preamble.
Disabling the preamble has a small savings in terms of overall packet length in most data modes, but can have a signifi-
In general a 2-3 symbol repetition with a pattern such as
0x3333 or 0x5555 should provide suitable performance.
Increasing the length of the preamble may help with correlation and packet reception in cases with higher interference,
borderline firmware timing, or other issues. Before using
other preamble patterns in a production application, their
performance should be thoroughly evaluated in the intended
environment.
7.4.1.2
Start of Packet
Start of packet (SOP) symbols are used to bound the beginning of the packet data, and also provide the added feature
of encoding the data rate for the remainder of the packet.
Use of SOP is required for GFSK and 8DR modes, but
optional for other modes. Use of SOP is also required in
order to make use of mixed mode systems and dynamic
data rate systems, in which the receiver automatically
detects and receives incoming packets at any data rate.
SOP is composed primarily of two symbols. Each symbol is
either a 32-chip or 64-chip PN code(LPstar does not support
64-chip PN code). This is even true of the raw GFSK mode.
PN codes used for SOP are different than PN codes used
for the data portion of the packet.
WirelessUSB LP family devices correlate packets based
upon SOP PN codes when enabled. What this means is that
if a receiver successfully correlates on an SOP, then the
receive state machine will run to completion and will receive
a packet, regardless of the validity of the remainder of the
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
63
Digital Baseband
data. Failing to correlate on an SOP results in no packet
being received even if valid data follows.
The modem uses SOP codes to provide additional bit centering, which is why they are required for 8DR and GFSK
modes. The centering algorithm looks at peaks at an over-
sampled rate of 6 MHz during the SOP phase. The receive
correlator performs a centered 3x over-sampling on the data
portion of the packet, but looking at a much narrower window around the pre-established bit center.
Figure 7-4. SOP Derived Bit Centering
SOP Correlation
6MHz over-sampling
Data Correlation
Centered 3x over-sampling
Peaks
Threshold
1 usec
1 usec
SOP derived
bit center
SOP is enabled or disabled with bit 7, SOP EN, of the
FRAMING_CFG_ADR register 0x10. The length, 32 chip or
64 chip, is set using bit 6, SOP LEN, of the
FRAMING_CFG_ADR register 0x10.
The SOP code itself is stored in the SOP_CODE_ADR file
register 0x22, which consists of eight bytes. When SOP LEN
is set to ‘0’, indicating 32 chips, only the first four bytes of
SOP_CODE_ADR are used. When reading or writing this
register the user must access all eight bytes to ensure the
file register is reset to the correct start position for the next
access.
Cypress has researched PN codes to determine codes with
properties acceptable for use by WirelessUSB LP family
systems. The first four bytes of these codes are suitable as
standalone 32-chip codes and the full eight bytes are satisfactory 64-chip codes.
Table 7-7. Cypress Recommended SOP PN Codes
SOP PN Codes
Data bit
centers
Table 7-7. Cypress Recommended SOP PN Codes
SOP PN Codes
0x3CDC829E3CDC78A1
0x7418656F74198EB9
0x49C1DF6249C0B1DF
0x72141A7F7214E597
The complete SOP portion of the packet consists of a single
symbol, followed by a possible 4-bit time delay, followed by
a second symbol, followed by a 1-bit time delay. The symbols are either normal or inverted transmissions of the SOP
PN code. The status of the PN code and the presence or
absence of the delay are used to encode the data rate for
the remainder of the packet.
Table 7-8. Data Rate Encoding in Start of Packet
Data Rate
1st Symbol
4 Bit Time
Delay
2nd Symbol
1 Bit Time
Delay
32-Chip DDR
SOP Code
No
SOP Code
Yes
0x91CCF8E291CC373C
64-Chip DDR
SOP Code
No
SOP Code
Yes
0x0FA239AD0FA1C59B
GFSK
SOP Code
No
SOP Code
Yes
0x2AB18FD22AB064EF
32-Chip 8DR
SOP Code
Yes
SOP Code
Yes
0x507C26DD507CCD66
64-Chip 8DR
SOP Code
Yes
SOP Code
Yes
0x44F616AD44F6E15C
ACK
SOP Code
No
SOP Code
Yes
0x46AE31B646AECC5A
When discussing co-location using channel and PN code to
distinguish between systems, it is the SOP PN codes and
not the data PN code that are used to provide co-location.
64
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Digital Baseband
7.4.1.3
Data
The data portion of the packet consists of the user’s data
bytes. Zero length packets are valid, and lengths can be up
to 40 bytes. Framed 64-chip DDR packets are further limited
to 16 bytes maximum length.
The 40 byte maximum packet size is based upon the crystal
tolerance specification of ±30 PPM. The transmitting and
receiving sides of the system can thus be off by as much as
60 PPM. At this extreme, up to 40 bytes can be received
without losing bit centering.
In theory larger length packets can be transmitted with
tighter tolerance; however, Cypress has not characterized
this usage. The 60 PPM tolerance must also consider all
factors such as temperature and aging variations of the
crystal. Thus 40 bytes is the recommended maximum
packet size.
Other factors may also have to be considered in selecting
the packet size appropriate for the application. Any given bit
has a certain probability of being affected by interference
and thus being corrupted. With DSSS data the probability is
much less than with raw GFSK data; however, in either case
a corrupted data bit will result in the entire packet being
flagged with an error. Thus large packets might have a
higher susceptibility to error, requiring re-transmission of the
data. Smaller packets have a higher overhead due to the
framing. One other factor to consider is that for packet
lengths greater than 16 bytes, the length of the transmit and
receive buffers, the application has to add or remove data to
prevent an under or over run condition. Each application will
have to evaluate the right balance.
Transmit data to be sent is written to the TX_BUFFER_ADR
file register 0x20. Any data in this buffer can be retransmitted without resetting and reloading the FIFO by setting
TX_GO again. Received data is read from the
RX_BUFFER_ADR file register 0x21.
There is also an optional capability to store data valid bits,
primarily for compatibility with the legacy WirelessUSB LS/
LR devices. This mode is set with bit 0, VLD EN, of the
RX_CFG_ADR register 0x06. In this case the received data
is presented with the byte of valid data bits. When the data is
stored in the receive data buffer, the eight valid bits for each
stored byte are stored in the next buffer location after the
data. Thus only eight bytes of the receive data buffer are
available for actual application data.
7.4.1.4
Length
Length is a 1 byte field. It is required in raw GFSK mode and
in 8DR mode. It is optional in other modes. Length is
enabled by setting bit 5, LEN EN, in the
FRAMING_CFG_ADR register 0x10.
A length of zero is valid, and will transmit a packet with SOP,
length, and CRC16 fields (if enabled), but no data field.
Packet lengths of more than 16 bytes require that some data
bytes be written after transmission of the packet has begun.
Typically, length is updated prior to setting TX GO. It is written to the TX_LENGTH_ADR register 0x01.
7.4.1.5
Cyclic Redundancy Check
An optional CRC16 is performed on data to see if an error
has occurred during the transmission of the packet. The
CRC16 is performed on only the length and data fields of
the packet. The CRC16 can be seeded with a user specified
16-bit value loaded into the CRC_SEED_LSB_ADR register
0x16 and CRC_SEED_MSB_ADR register 0x16. The RX
Framer CRC16 check is not only against the seeded value,
but may also be configured to simultaneously check the
received data against the zero-seeded value. Received data
that fails the CRC16 check is flagged with an error, but is still
available to the application.
Multiple registers control how the CRC16 is used. Bit 2, DIS
TXCRC, of the TX_OVERRIDE_ADR register 0x1F determines whether or not a CRC16 value is calculated and
appended to the data packet. When set, no CRC16 is used.
Bit 2, DIS RXCRC, of the RX_OVERRIDE_ADR register
0x1E determines whether or not the receive CRC checker is
enabled. The user should ensure that DIS TXCRC and DIS
RXCRC are matched on both sides of the RF link. Bit 3, DIS
CRC0, of the RX_OVERRIDE_ADR causes the receiver to
reject packets that match a zero CRC16 seed when set. Bit
1, ACE, of the RX_OVERRIDE_ADR allows the receiver to
accept packets that do not match the CRC16 seed. Both of
these last two bytes affect whether or not CRC16 errors are
flagged on the received packet and Auto ACKs are sent
(when enabled). If desired the CRC16 calculated results can
be read at the TX_CRC_LSB_ADR register 0x16 and the
TX_CRC_MSB_ADR register 0x18 on the transmit side and
the RX_CRC_LSB_ADR register 0x19 and the
RX_CRC_MSB_ADR register 0x20 on the receive side.
For CRC16 generation and checking, the shift registers in
the receive and transmit framers are seeded with the specified pattern. For each data bit sent or received, the high
order bit of the current remainder is XORed with the data bit
and then the remainder is shifted left one bit and the loworder bit set to zero. If the result of that XOR is one, then the
remainder is XORed with the generator polynomial. When
the last bit of the checked field is sent, the CRC16 in the
transmit framer is inverted and appended to the packet.
When the last bit of the CRC16 is received by the receive
framer and no errors have occurred, the remainder is equal
to the polynomial residual. A CRC16 error exists if the computed checksum remainder at the end of a packet reception
does not match the residual.
The CRC16 can be represented as a polynomial as shown
below.
G(X) = X16 + X15 + X2 + 1
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
65
Digital Baseband
This method provides 100% coverage on single and double
bit errors. It can also detect an odd number of bit errors and
any error as wide as the CRC16 field itself.
specified length of time before it can determine that an end
of packet was previously reached. Therefore, the receive
event is delayed for a longer time past the end of the packet.
Using a known CRC16 seed can be used to distinguish link
data, and provides an additional method of co-locating systems. Allowing for the additional zero seed allows ‘new’
devices to connect to a host prior to being given a seed
value.
When the hint enable field is set, the more sophisticated
mechanism is used. An EOP is detected if no correlations
have been detected for the configured number of symbol
periods and the last two received bytes match the calculated
CRC for all previously received bytes. The desired number
of symbol periods is set using bits 6:4, HINT, of the
EOP_CTRL_ADR register 0x14.
A two stage pipeline before the receive FIFO is used to prevent the CRC16 from being written to the RX FIFO in the
case where no length field is available and EOP detection is
relied upon.
7.4.2
ACK Packets
ACK packets consist of preamble, SOP, and CRC16 (when
enabled). In order for a transaction with an automated ACK
response to complete successfully when CRC16 is enabled,
the CRC in the received ACK must match the CRC transmitted in the last packet. The data mode of the CRC portion of
a transmitted ACK must also match the data mode of the
last received data packet.
In the absence of chip errors, the hinting scheme causes an
EOP to be detected on the very first invalid bit, thereby,
shutting down the receiver quickly. For lower data rates this
EOP delay would be shorter than that required to send a
length field. However, there is a risk that a single invalid bit
would cause a packet to be ‘truncated’ if it occurred at the
right byte boundary where the data was such that the interim
CRC value was also seen as good.
Automatic transmission of ACK packets is enabled by setting bit 7, ACK EN, of the XACT_CFG_ADR register 0x0F.
7.4.3
End of Packet Detection
There are multiple methods of end of packet detection.
These include length field detection and different variations
of non-correlation.
The most reliable method is to use framed packets with the
length field enabled. In this case, end of packet detection is
explicitly based upon the number of data bytes specified in
the length field plus the CRC16 (if enabled). Using the
length field allows for a faster turn around. In rare cases, it is
possible for the length field to be corrupted during transmission, thus resulting in an unplanned amount of data being
received – either too short with the remainder of the legitimate data lost, or too long with random data filling the extra
bytes. An erroneously long length field will also tie up the
correlator for the amount of time required to receive a packet
of the erroneous length.
If the length field is disabled, then the receiver must rely
upon non-correlation for end of packet detection. There are
two schemes for this: a fixed length of non-correlations
(invalid bits) and a more sophisticated mode where after the
‘hint’ interval the received CRC is checked and if good, the
EOP is detected at that point.
To use the fixed number of non-correlations the hint enable
field must be cleared. This is done by setting bit 7, HEN, of
the EOP_CTRL_ADR register 0x14 to ‘0’. Bits 3:0, EOP, of
that register set the number of successive symbol non-correlations that are required to determine an EOP condition.
The disadvantage of this mechanism is that the correlator
must continue running past the end of the packet for the
66
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
8. Radio Initialization and Operation
8.1
Introduction
The intent of the radio driver is to provide users with a consistent interface to the radio. The driver was designed to interface
with both C and assembly written applications and consists of the following files:
Table 8-1. Radio Driver Files
File Name
Description
lpstreaming.asm
Core functions responsible for transmitting and receiving data in packets up to 254 bytes in length. This version of the driver
manages the radio transmit and receive FIFO’s by moving data in bursts of 8 bytes.
lpnonstreaming.asm
Core functions responsible for transmitting and receiving data in packets up to 16 bytes in length. This version of the driver is
simpler and smaller than the streaming version.
Note: lpstreaming.asm and lpnonstreaming.asm implement the same API functions - only one of them should be used as part of a project.
lpradio.asm
API functions primarily responsible for radio configuration and status and variable allocation.
lpradio.h
'C' function prototypes and type declarations for the entire radio driver - functions implemented in lpstreaming.asm or lpnonstreaming.asm, lpradio.asm and psocradio.asm or e2radio.asm.
lpradio.inc
Symbolic definitions used in lpstreaming.asm, lpnonstreaming.asm, lpradio.asm, psocradio.asm, and e2radio.asm.
lpregs.h
'C' defines for the radio registers and register fields.
lpregs.asm
Assembly symbolic definitions for the radio registers and register fields.
psocradio.asm
Low level radio interface routines provide SPI access for register read and write for single registers, file registers and bursts
using the PSoC SPI interface.
e2radio.asm
Low level radio interface routines provide SPI access for register read and write for single registers, file registers and bursts
using the enCoRe II SPI interface.
Note: psocradio.asm and e2radio.asm implement the same API functions - only one of them should be used as part of a project.
irqmacros.inc
Support macros for M8C global IRQ management.
irqmacros.asm
Variable allocation for irqmacros.asm.
The radio driver supports various application and hardware
requirements. Projects that use packets larger than 16 bytes
must use lpstreaming.asm. Projects using packets less than
or equal to 16 bytes should use lpnonstreaming.asm. The
hardware specific SPI interface files psocradio.asm and
e2radio.asm provide hardware SPI interface calls for the
radio driver. psocradio.asm provides SPI communication for
all PSoC based applications whereas e2radio.asm is to be
used for enCoRe II based applications.
In addition to the SPI interface signals LP_nSS, SCK, MOSI,
MISO, the radio driver also requires access to the IRQ output of the radio. This pin must be named LP_IRQ.
8.2
Usage
This section presents information on radio initialization and
methods for transmitting and receiving. For the developing
applications in LPstar, please use the radio driver from the
application note-AN68105-Migration of WirelessUSB™ LP
Designs to WirelessUSB™ LPstar.
8.2.1
Initialization
Before the radio can be used it must first be initialized using
the API call RadioInit with parameters to be used for the
XACT_CFG_ADR and TX_CFG_ADR registers. These two
registers define the end state of the radio and the data mode
to be used. Refer to the data sheet for specifics, see
Cypress Semiconductor Support on page 9. Example
usage:
RadioInit(ACK_EN|END_STATE_SLEEP|ACK_TO_15X,
DEFAULT_PA|DATCODE_LEN_32|DATMODE_8DR);
All other aspects of radio initialization and configuration, with
the exception of XACT_CFG_ADR and TX_CFG_ADR are
the responsibility of the application and must be done prior
to starting a transmit or receive operation.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
67
Radio Initialization and Operation
8.2.2
8.3
Transmitting
Requirements
There are two types of transmit functions: blocking and nonblocking. Blocking does not return until the transmit process
has completed. In the non-blocking case, the function starts
the transmit and then returns. It is the responsibility of the
calling application to monitor the stare of the transmit and
terminate when necessary. Both forms of transmit require a
call to RadioSetPtr with a buffer address as a parameter.
This pointer points to the start of the buffer to be transmitted.
Radio header file requirements and hardware interface and
pin requirement are discussed in this section.
Table 8-2. Transmit Example
8.3.2
Blocking
8.3.1
Header Files
In order to use the radio driver you must include lpradio.h
and lpradio.inc into any file that calls the radio driver functions.
Hardware Interface
Non-Blocking
RadioSetPtr
RadioSetPtr
RadioBlockingTransmit
The SPI block used to interface to the radio is named:
SPIM_Radio. This block provides the firmware interface to
the SPI pins, so their names have no requirements.
RadioStartTransmit
RadioGetTransmitState
8.3.3
Pins
RadioEndTransmit
8.2.3
The pin connected to the radio's slave select pin must be
called LP_nSS. The pin connected to the radio's IRQ pin
must be named LP_IRQ.
Receiving
By nature, receives are non-blocking and require a similar
set of calls as was used in the non-blocking transmit case. In
the event that a receive must be aborted then RadioAbort
must be called. Note Once a receive is started, no calls can
be made to the configuration access routines until the
receive operation is terminated.
Table 8-3. Receive Example
Non-Blocking
RadioSetPtr
RadioStartReceive
RadioGetReceiveState
RadioEndReceive
68
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.4
Type Declarations
The type declarations are described below.
Table 8-4. Type Declarations
Type Declaration
Description
BYTE
Used for 8-bit register values
WORD
Used for 16-bit register values.
RADIO_CONST_PTR
Used for ROM buffer pointers.
RADIO_BUFFER_PTR
Used for RAM buffer pointers.
RADIO_LENGTH
#define RADIO_ABORT_SUCCESS
255
RADIO_REG_ADDR
Used for radio field lengths.
Used for Radio register addresses.
RADIO_STATE
typedef unsigned char RADIO_STATE;
#define RADIO_IDLE
0x00
#define RADIO_RX
0x80
#define RADIO_TX
0x20
#define RADIO_DATA
RXB1_IRQ
#define RADIO_COMPLETE
RXC_IRQ
#define RADIO_ERROR
RXE_IRQ
See the definition of RadioState below for more detail on
the meanings of these bits.
RADIO_RX_STATUS
typedef unsigned char RADIO_RX_STATUS;
#define RADIO_RX_ACK
0x80
#define RADIO_RX_MISS
0x40
#define RADIO_RX_OF
0x20
#define RADIO_RX_CRC0
0x10
#define RADIO_BAD_CRC
0x08
#define RADIO_DATCODE_LEN
0x04
#define RADIO_SDR
0x03
#define RADIO_DDR
0x02
#define RADIO_8DR
0x01
#define RADIO_GFSK
0x00
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
69
Radio Initialization and Operation
8.5
Radio High Level Functions
These functions provide configuration, transmit, and receive functionality.
8.5.1
RadioInit
Description:
This function calls RadioReset then initializes the state of the radio as used by the radio driver. This includes setting the
transmit offset to 1 MHz – the same as the receiver IF frequency to allow zero turn-around time for the fastest possible
transitions between transmit and receive modes and minimal auto-ACK time. All other aspects of radio initialization and
configuration, with the exception of XACT_CFG_ADR and TX_CFG_ADR, are the responsibility of the application and
must be done prior to starting a transmit or receive operation.
Example:
RadioInit(ACK_EN | END_STATE_SLEEP | ACK_TO_15X,
DEFAULT_PA | DATCODE_LEN_32 | DATMODE_8DR);
C Prototype:
void RadioInit(XACT_CONFIG xactConfig, TX_CONFIG txConfig);
Assembly:
A: xactConfig
X: txConfig
Parameters:
xactConfig: Specifies the end state of the radio and the data mode to be used.
txConfig: Specifies the data mode to be used.
Symbolic names provided in C and assembly, and their associated values, are given in the following table.
Symbolic Name
Value
Description
Return Value:
A: Undefined
X: Undefine
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
70
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.2
RadioSetChannel
Description:
This function sets the radio channel to a specified frequency. The frequency has the value of frequency + 2402 MHz. This
function takes an 8-bit argument that is passed to it by BYTE channel.
Example:
RadioSetChannel(10); // Put carrier at 2.412GHz
C Prototype:
void RadioSetChannel(BYTE channel);
Assembly:
A: channel
X: Unused
Parameters:
channel: Specifies the channel used.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
8.5.3
RadioSetFrequency
Description:
This function sets the frequency in MHz above 2.400 GHz. Example: 0 means 2.400 GHz, 83 means 2.483 GHz. This
function sets the radio frequency to one where communication occurs. This function takes an 8-bit argument that is
passed to it and writes it into the channel register.
The receiver has an Intermediate frequency of 1 MHz; that means that the PLL frequency and actual RF carrier frequency are 1 MHz apart. RadioInit sets the transmit offset at 1 MHz, which means that the transmit carrier is also 1 MHz
higher than the PLL frequency that is programmed. This function compensates for the 1 MHz by decrementing the
passed frequency so that the passed frequency is the carrier frequency, not the PLL frequency, which is 1 MHz lower.
Example:
RadioSetFrequency(10); // Put carrier at 2.410GHz
C Prototype:
void RadioSetFrequency(BYTE frequency);
Assembly:
A: frequency
X: Unused
Parameters:
frequency: Specifies the actual RF carrier frequency.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
71
Radio Initialization and Operation
8.5.4
RadioGetChannel
Description:
This function gets the 8-bit value from the channel; that value is the frequency –2.
Example:
RadioSetFrequency(10); // Put carrier at 2.410GHz
c = RadioGetChannel(); // Returns 8.
C Prototype:
BYTE RadioGetChannel(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: channel
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
8.5.5
RadioGetFrequency
Description:
This function returns the frequency value from the channel address in MHz above 2.4 GHz. Example: 0 means
2.400 GHz, 83 means 2.483 GHz.
C Prototype:
BYTE RadioGetFrequency(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: frequency
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
72
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.6
RadioSetTxConfig
Description:
This function sets the transmitter configuration. The transmitter configuration is also set when initializing the radio by calling RadioInit. Both of these functions write the same register in the radio.
This example sets a 250 kbps transmit configuration using 32 chips per byte, 8DR encoding, and a transmit power of
-15 dBm:
RadioSetTxConfig(DATCODE_LEN_32 | DATMODE_8DR | PA_N15_DBM);
C Prototype:
void RadioSetTxConfig(TX_CONFIG config);
Assembly:
A: Unused
X: Unused
Parameters:
config: Specifies the transmitter configuration.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
8.5.7
RadioGetTxConfig
Description:
This function returns the transmitter configuration.
This example sets a transmit power of 0dBm:
RadioSetTxConfig((RadioGetTxConfig() & ~PA_VAL_MSK) | PA_0_DBM);
C Prototype:
TX_CONFIG RadioGetTxConfig(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: config
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
73
Radio Initialization and Operation
8.5.8
RadioSetXactConfig
Description:
This function sets the transaction configuration. This function can be used to change the end state, the state the radio
moves to after completing an operation, but cannot be used to force the radio into that new end state.
If you need to change the current state of the radio, for example from idle to sleep, follow the call to RadioSetXactConfig
with a call to RadioAbort:
RadioSetXactConfig(ACK_EN | END_STATE_SLEEP | ACK_TO_8X);
RadioAbort();
C Prototype:
void RadioSetXactConfig(XACT_CONFIG config);
Assembly:
A: config
X: Unused
Parameters:
config: Specifies the value to be written to the XACT_CFG_ADR register.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
8.5.9
RadioGetXactConfig
Description:
This function returns the transaction configuration register: XACT_CFG_ADR.
For example, to turn off the auto-ACK function:
RadioSetXactConfig(RadioGetXactConfig() & ~ ACK_EN);
C Prototype:
XACT_CONFIG RadioGetXactConfig(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: config
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
74
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.10
RadioSetFrameConfig
Description:
This function sets the framing configuration value in the FRAMING_CFG_ADR register. For example, with this call the
radio is set to framed, 64-chip SOP, with length fields and a SOP threshold of 8:
RadioSetFrameConfig(SOP_EN | SOP_LEN | LEN_EN | 8);
C Prototype:
void RadioSetFrameConfig(RADIO_FRAME_CONFIG config);
Assembly:
A: config
X: Unused
Parameters:
config: Value to be written to the FRAMING_CFG_ADR register.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
8.5.11
RadioGetFrameConfig
Description:
This function returns the current framing configuration from the FRAMING_CFG_ADR register.
For example, to force the length field enabled:
RadioSetFrameConfig(RadioGetFrameConfig() | LEN_EN);
C Prototype:
RADIO_FRAME_CONFIG RadioGetFrameConfig(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: config
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
75
Radio Initialization and Operation
8.5.12
RadioSetThreshold32
Description:
This function sets the data threshold for the 32-chip data modes.
Example:
RadioSetThreshold32(5);
C Prototype:
void RadioSetThreshold32(BYTE threshold);
Assembly:
A: threshold
X: Unused
Parameters:
threshold: 8-bit value that is passed to the function.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
8.5.13
RadioGetThreshold32
Description:
This function returns the threshold for the 32-chip data modes.
C Prototype:
BYTE RadioGetThreshold32(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: threshold
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function.
The same is true for all RAM page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve the values across calls
to fastcall16 functions.
76
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.14
RadioSetThreshold64
Description:
This function sets the threshold for the 64-chip data modes.
C Prototype:
void RadioSetThreshold64(BYTE threshold);
Assembly:
A: threshold
X: Unused
Parameters:
threshold: 8-bit value passed to the function.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.15
RadioGetThreshold64
Description:
This function returns the threshold for the 64-chip data modes. The threshold value is in the DATA64_THOLD_ADR register.
C Prototype:
BYTE RadioGetThreshold64(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: threshold
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
77
Radio Initialization and Operation
8.5.16
RadioSetPreambleCount
Description:
This function sets the preamble repetition count. The preamble repetition count is the number of times the 16-chip preamble pattern is repeated prior to the SOP code for packets transmitted.
C Prototype:
void RadioSetPreambleCount(BYTE count);
Assembly:
A: count
X: Unused
Parameters:
count: 8-bit value that is passed to the function.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.17
RadioGetPreambleCount
Description:
This function returns the preamble repetition count.
Example:
printf("The preamble is %d chips long.\r\n", RadioGetPreambleCount() * 16);
C Prototype:
BYTE RadioGetPreambleCount(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: count
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
78
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.18
RadioSetPreamblePattern
Description:
This function sets the preamble pattern. The preamble pattern is transmitted at the chip rate, 1 µs per bit, prior to the
SOP for all packets. The pattern is repeated the number of times specified by the preamble repetition count.
C Prototype:
void RadioSetPreamblePattern(WORD pattern);
Assembly:
A: pattern low order
X: pattern high order
Parameters:
pattern: Specifies the 16-bit pattern.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.19
RadioGetPreamblePattern
Description:
This function returns the current 16-bit preamble pattern.
C Prototype:
WORD RadioGetPreamblePattern(void);
Assembly:
A: Unused
X: Unused
Parameters:
pattern: Specifies the 16-bit pattern.
Return Value:
A: pattern low order
X: pattern high order
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
79
Radio Initialization and Operation
8.5.20
RadioSetCrcSeed
Description:
This function sets the value used as the CRC seed-value for both transmit and receive. The CRC seed value of 0x0000 is
special in that the receiver can correctly CRC check packets transmitted with a CRC seed of 0x0000 even if the receiver
CRC seed is set to a different value.
This allows cross-network broadcasting in systems that use CRC seed as part of the system network identifier.
C Prototype:
void RadioSetCrcSeed(WORD crcSeed);
Assembly:
A: crcSeed low order
X: crcSeed high order
Parameters:
crcSeed: The crcSeed value.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.21
RadioGetCrcSeed
Description:
This function returns the value used as the CRC seed-value for both transmit and receive.
C Prototype:
WORD RadioGetCrcSeed(void);
Assembly:
A: Unused
X: Unused
Parameters:
crcSeed: The crcSeed value.
Return Value:
A: crcSeed low order
X: crcSeed high order
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
80
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.22
RadioGetFuses
Description:
This function gets the fuse values from the radio. The six bytes of fuse data are stored at the buffer pointed to by the most
recent call to RadioSetPtr.
Example:
unsigned char fuses[6];
RadioSetPtr(fuses);
RadioSetLength(sizeof(fuses));
RadioGetFuses();
C Prototype:
void RadioGetFuses(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.23
RadioGetRssi
Description:
This function returns the Receive Signal Strength Indicator value. When read after a receive has completed, this is the
signal strength for the received packet. While in the receive state, but before a packet has been received, this function
can be called continuously to check the carrier strength at the current frequency. When used in this continuous mode, the
first value returned is garbage and should be discarded.
C Prototype:
RADIO_RSSI RadioGetRssi(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
81
Radio Initialization and Operation
8.5.24
RadioSetConstSopPnCode
Description:
This function sets the Start Of Packet PN Code. This function can be used to set arbitrary SOP PN codes. Great care
should be taken in selecting PN Codes – poorly formed PN codes can substantially reduce or negate radio performance.
C Prototype:
void RadioSetConstSopPnCode(const BYTE *patternAddr);
Assembly:
A: patternAddr address high
X: patternAddr address low
Parameters:
patternAddr: Const (ROM) pointer to the 8 byte SOP PN code.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.25
RadioSetConstDataPnCode
Description:
This function sets the data PN Code. This function can be used to set arbitrary Data PN codes. Great care should be
taken in selecting PN Codes – poorly formed PN codes can substantially reduce or negate radio performance.
C Prototype:
void RadioSetConstDataPnCode(const BYTE *patternAddr);
Assembly:
A: patternAddr address high
X: patternAddr address low
Parameters:
patternAddr Const: Const (ROM) pointer to the 8-byte data PN code.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
82
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.26
RadioSetSopPnCode
Description:
This function sets the start-of-packet PN code from a table of codes embedded in the radio driver. The PN code table in
the driver contains 10 PN codes, with another 10 that can be added if wanted.
C Prototype:
void RadioSetSopPnCode(BYTE patternNum);
Assembly:
A: patternNum
X: Unused
Parameters:
patternNum: Array index for the 8-byte SOP PN code.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.27
RadioStartTransmit
Description:
This function starts the non-blocking transmission of a packet. The location of the packet buffer to transmit must have
previously been set with a call to RadioSetPtr.
After starting the transmission of a packet with this call, the state of the transmit operation must be checked by calling
RadioGetTransmitState. When RadioGetTransmitState indicates that the transmission has completed a call must be
made to RadioEndTransmit.
Note After calling RadioStartTransmit, no calls can be made to the configuration access routines until the transmit operation is terminated with a call to RadioEndTransmit or RadioAbort. Until one of those calls is made to end the transmit
operation the only other call supported is RadioGetTransmitState.
Example:
unsigned char bufferToTransmit[14] = "PacketPayload";
RADIO_STATE txState;
RadioSetPtr(bufferToTransmit);
RadioStartTransmit(0, sizeof(bufferToTransmit));
while (!((txState = RadioGetTransmitState()) & RADIO_COMPLETE)) {
CallSomeRoutineToGetWorkDoneWhileWaitingForTransmitToComplete();
}
RadioEndTransmit();
if (txState & RADIO_ERROR) printf("Transmit failed.\r\n");
C Prototype:
void RadioStartTransmit(BYTE retryCount, RADIO_LENGTH length);
Assembly:
A: retryCount
X: length
Parameters:
retryCount: Number of times the packet should be retried it the transmit fails.
length:Length, in bytes, of the packet.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
83
Radio Initialization and Operation
8.5.28
RadioGetTransmitState
Description:
This function returns the state of the current transmit operation. This call must be made after starting a transmit operation
with the RadioStartTransmit function. The value returned is of the type RADIO_STATE which includes some bits maintained by the radio driver itself and some bits that are read from the TX_IRQ_STATUS_ADR register.
Although the bits in the status register in the hardware clear automatically, RadioEndState returns a status value that
holds the status bits until RadioEndReceive is called.
C Prototype:
RADIO_STATE RadioGetTransmitState(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: RadioState
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.29
RadioEndTransmit
Description:
This function completes a transmit operation.
C Prototype:
void RadioEndTransmit(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
84
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.30
RadioAbort
Description:
This function aborts a receive operation or forces the radio state while idle. RadioAbort must not be called while the radio
is performing a transmit operation.
In the case where a receive operation is currently in progress it is possible that the receive operation completes (successfully or with an error) prior to the RadioAbort call. If this is the case the value returned is the length of a packet
received without errors. If auto-ACK is enabled, the packet has been ACK'ed as well. Regardless of whether the RadioAbort call returns a packet (if called during a receive operation) when the call returns, the radio will be idle – or whatever
the current end state is.
If the radio is not performing a receive operation, it always returns RADIO_ABORT_SUCCESS.
Example:
unsigned char receiveBuffer[16];
RADIO_LENGTH rxAbortStatus;
RadioSetPtr(receiveBuffer);
RadioSetLength(sizeof(receiveBuffer));
RadioStartReceive();
rxAbortStatus = RadioAbort();
if (rxAbortStatus != RADIO_ABORT_SUCCESS)
printf("Received %d byte packet.\r\n", rxAbortStatus);
RadioAbort can also be used to force the radio into the current end state as specified in the transaction control register.
RadioSetXactConfig(ACK_EN | END_STATE_SLEEP | ACK_TO_8X);
RadioAbort();
C Prototype:
RADIO_LENGTH RadioAbort(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: length
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
85
Radio Initialization and Operation
8.5.31
RadioBlockingTransmit
Description:
This function transmits a packet; it blocks execution until it completes. This function attempts to transmit a packet. The
address of the packet buffer should have previously been set with a call to RadioSetPtr.
This routine gives the user very little control – probably less than most applications require. This function is primarily
intended for very simple applications that have no use for a timeout.
Example:
unsigned char bufferToTransmit[14] = "PacketPayload";
RADIO_STATE txState;
RadioSetPtr(bufferToTransmit);
txState = RadioBlockingTransmit(4, sizeof(bufferToTransmit));
if (txState & RADIO_ERROR)
printf("Transmit failed after 5 attempts.\r\n");
C Prototype:
RADIO_STATE RadioBlockingTransmit(BYTE retryCount, RADIO_LENGTH length);
Assembly:
A: retryCount
X: length
Parameters:
retryCount: Number of times the packet should be retried it the transmit fails.
length:Length, in bytes, of the packet.
Return Value:
A: RadioState
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
86
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.32
RadioStartReceive
Description:
This function starts the reception of a packet. The location and length of the packet buffer to receive the data into must
have previously been set with calls to RadioSetPtr and RadioSetLength.
After starting the reception of a packet with this call, the state of the receive operation must be checked by calling RadioGetReceiveState. When RadioGetReceiveState indicates that the transmission has completed, a call must be made to
RadioEndReceive.
After calling RadioStartReceive NO CALLS can be made to the configuration access routines until the receive operation
is terminated with a call to RadioEndReceive or RadioAbort.
Until one of those calls is made to end the receive operation, the only other calls supported are RadioGetReceiveState
and RadioGetRssi.
C Prototype:
void RadioStartReceive(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
87
Radio Initialization and Operation
8.5.33
RadioGetReceiveState
Description:
This function returns the state of the current receive operation. This call should be made after starting a receive operation
with the RadioStartReceive function.
The value returned is of the type RADIO_STATE, which includes some bits maintained by the radio driver itself and some
bits that are read from the RX_IRQ_STATUS_ADR register. Although the hardware bits clear automatically, the driver
makes make them sticky until the RadioEndReceive.
Example:
RadioStartReceive(); // Start the receiver
while(1) {
unsigned char ReceivedPayloadSize;
RADIO_STATE rxState;
RADIO_RX_STATUS rxStatus;
rxState = RadioGetReceiveState();
if (rxState & RADIO_COMPLETE) {
ReceivedPayloadSize = RadioEndReceive();
if (!(rxState & RADIO_ERROR)) {
++ReceivedCount; // Successfully received a packet
}
else {
RxStatus = RadioGetReceiveStatus();
// Handle various error types here.
}
}
C Prototype:
RADIO_STATE RadioGetReceiveState(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: RadioState
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
88
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.34
RadioEndReceive
Description:
This function completes a receive operation; it returns the length of the packet that was received. If the packet payload
truncation occurs (due to inadequate buffer length) it does not change this return value.
C Prototype:
RADIO_LENGTH RadioEndReceive(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: length
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.5.35
RadioGetReceiveStatus
Description:
The status register includes information about the encoding of the most recently received packet and if there was an
error, the cause of the error.
C Prototype:
RADIO_RX_STATUS RadioGetReceiveStatus(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: status
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
89
Radio Initialization and Operation
8.5.36
RadioInterrupt
Description:
This function manages the radio in an ISR.
For interrupt-based systems RadioInterrupt can be called from the GPIO interrupt. This function does nothing if the IRQ is
not asserted thereby making it easy to share the IRQ with other GPIO interrupts.
Using this function in an IRQ can eliminate latency caused by calling RadioGetTransmitState and/or RadioGetReceveiveState in a polling loop. When using this routine to maintain the radio, the state of that maintenance is communicated
to the outside code through the global variable RadioState.
RadioInterrupt terminates with a RETI. It is intended to be the target of a JMP instruction from the interrupt vector directly
in systems where the radio does not share the GPIO interrupt, or it can be JMP'd to at the end of an ISR that manages
the other GPIO interrupt sources in a system.
Because RadioInterrupt is intended to be JMP'd to from the interrupt vector it leaves the registers unaffected.
Example (In boot.tpl / boot.asm):
org
1Ch
;GPIO Interrupt Vector
ljmp RadioInterrupt
; `@INTERRUPT_7`
...elsewhere:
while (1) {
if (RadioState & RADIO_RX) {
if (RadioState & RADIO_COMPLETE) {
if (!RadioState & RADIO_ERROR) {
length = RadioEndReceive();
}
}
} else if (RadioState & RADIO_TX) {
if (RadioState & RADIO_COMPLETE) {
if (!RadioState & RADIO_ERROR) {
RadioEndTransmit();
}
}
}
}
C Prototype:
void RadioInterrupt(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
90
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.5.37
RadioPoll
Description:
RadioPoll can be used in a polling loop to replace the use of RadioInterrupt in an interrupt handler. This allows most of
the radio state management code to be the same as it is in the case where RadioInterrupt is being used. Note in the
example below that the radio state management is the same as the RadioInterrupt example above. The only difference is
the addition of the RadioPoll() call to replace the use of RadioInterrupt in an interrupt handler.
Example:
while (1) {
RadioPoll();
if (RadioState & RADIO_RX) {
if (RadioState & RADIO_COMPLETE) {
if (!RadioState & RADIO_ERROR) {
length = RadioEndReceive();
}
}
} else if (RadioState & RADIO_TX) {
if (RadioState & RADIO_COMPLETE) {
if (!RadioState & RADIO_ERROR) {
RadioEndTransmit();
}
}
}
}
C Prototype:
void RadioPoll(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
91
Radio Initialization and Operation
8.5.38
RadioState
Description:
RADIO_STATE is a global variable that contains the most recent return value from RadioGetReceiveState or RadioGetTransmitState. This value can be used in lieu of those return values; this is especially useful when using RadioInterrupt or RadioPoll to perform radio state management.
RadioState can even be used in lieu of the return values from RadioGetReceiveState or RadioGetTransmitState calls; for
example, to save storage to contain a return value or to simplify code architecture.
The following are values for RadioState:
RADIO_IDLE
When the radio is not performing a transmit or receive operation SradioState is RADIO_IDLE.
RADIO_RX
When the radio is performing a receive operation, the RADIO_RX bit is set. This bit is set between
calls to RadioStartReceive and RadioEndReceive.
RADIO_TX
When the radio is performing a receive operation, the RADIO_RX bit is set. This bit is set between
calls to RadioStartTransmit and RadioEndTransmit.
RADIO_DATA
During a receive operation, this bit indicates that some data has been received. This bit is not set during a transmit operation.
RADIO_COMPLETEThis bit, when set indicates that the current transmit or receive operation is complete.
RADIO_ERROR This bit, when set indicates that the current transmit or receive operation ended in an error. This bit is
only set when the RADIO_COMPLETE bit is set.
C Prototype:
extern RADIO_STATE RadioState;
Assembly:
A: n/a
X: n/a
Parameters:
None.
Return Value:
A: RadioState
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
92
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.6
Radio SPI Access Routines
These routines allow access directly to the radio registers. Most applications do not need to use these routines, instead relying on the functions provided by the radio driver's higher-level functions.
8.6.1
RadioReset
Description:
This routine resets the radio via MODE_OVERRIDE_ADR.RST=1.
C Prototype:
void RadioReset(void);
Assembly:
A: Unused
X: Unused
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.6.2
RadioRead
Description:
This routine reads a single byte from a radio register. For both the 'C' and assembly call, the top two bits of the register
address must be cleared.
C Prototype:
BYTE RadioRead(RADIO_REG_ADDR regAddr);
Assembly:
A: regAddr
X: Unused
Parameters:
None.
Return Value:
A: value
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
93
Radio Initialization and Operation
8.6.3
RadioWrite
Description:
This routine writes a single byte to a radio register. For both the 'C' and assembly call, the top two bits of the register
address must be cleared.
C Prototype:
void RadioWrite(RADIO_REG_ADDR regAddr, BYTE value);
Assembly:
A: regAddr
X: value
Parameters:
None.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.6.4
RadioSetPtr
Description:
This routine sets the buffer pointer address for the RadioBurstRead, RadioFileRead, RadioBurstWrite, and RadioFileWrite functions.
C Prototype:
void RadioSetPtr(unsigned char ramPtr);
Assembly:
A: ramPtr
X: Unused
Parameters:
RamPtr. Pointer to RAM buffer for future operations.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
94
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.6.5
RadioSetLength
Description:
This routine sets the buffer length used by RadioBurstRead and RadioFileRead functions. When the length of the buffer
is exhausted, reads continue to occur but the data is thrown away.
This example reads only the first four bytes of fuse data:
unsigned char buffer[4];
RadioSetPtr(buffer);
RadioSetLength(sizeof(buffer));
RadioReadFuses();
C Prototype:
void RadioSetLength(RADIO_LENGTH length);
Assembly:
A: Unused
X: Unused
Parameters:
length:Length of buffer pointed to by most recent call to RadioSetPtr.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.6.6
RadioBurstWrite
Description:
This routine writes a sequence of bytes to a sequence of radio registers. Prior to the RadioBurstWrite call, the developer
must make a call to RadioSet Ptr with the address of the data buffer containing the data to write.
The following example writes register addresses 0-7 of the radio. For both the 'C' and assembly call, the top two bits of
the register address must be cleared.
unsigned char buffer[8];
…later…
RadioSetPtr(buffer);
RadioBurstWrite(0, 8);
C Prototype:
void RadioBurstWrite(RADIO_REG_ADDR regAddr, BYTE cnt);
Assembly:
A: regAddr
X: cnt
Parameters:
regAddr: Address of buffer to write. The register address is incremented after each byte.
cnt: Length of the buffer.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
95
Radio Initialization and Operation
8.6.7
RadioFileWrite
Description:
This routine writes a sequence of bytes to a single radio register. For both the 'C' and assembly call, the top two bits of
the register address must be cleared. It must call RadioSetPtr prior to RadioFileWrite.
C Prototype:
void RadioFileWrite(RADIO_REG_ADDR regAddr, BYTE cnt);
Assembly:
A: regAddr
X: cnt
Parameters:
regAddr: Address of buffer to write.
cnt: Length of the buffer.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
8.6.8
RadioBurstRead
Description:
This routine reads ‘cnt’ bytes from consecutive register addresses starting with address ‘regAddr’. The address and
length of the buffer used to store the data need to be set with calls to RadioSetPtr and RadioSetLength prior to the call to
RadioBurstRead. For both the 'C' and assembly call, the top two bits of ‘regAddr’ must be cleared.
In the following example 10 bytes are read from radio registers 0-9, but only the first 8 are stored in the buffer. The extra
two bytes are thrown away:
unsigned char buffer[8];
RadioSetPtr(buffer);
RadioSetLength(sizeof(buffer));
RadioBurstRead(0, sizeof(buffer)+2);
C Prototype:
void RadioBurstRead(RADIO_REG_ADDR regAddr, BYTE cnt);
Assembly:
A: regAddr
X: cnt
Parameters:
regAddr: Address of buffer to read. The first register number to read. Subsequent reads come from incrementing register
addresses.
cnt: Length of the buffer.
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
96
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Radio Initialization and Operation
8.6.9
RadioFileRead
Description:
This routine reads a sequence of bytes from a single radio register. This function is the same as RadioBurstRead except
that all the data is read from a single register and the address does not increment. For both the 'C' and assembly call,
the top two bits of the register address must be cleared.
C Prototype:
void RadioFileRead(RADIO_REG_ADDR regAddr, BYTE cnt);
Assembly:
A: regAddr
X: cnt
Parameters:
A: regAddr
X: cnt
Return Value:
A: Undefined
X: Undefined
Side Effects:
The A and X registers may be modified by this or future implementations of this function. The same is true for all RAM
page pointer registers in the Large Memory Model. When necessary, it is the calling function's responsibility to preserve
the values across calls to fastcall16 functions.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
97
Radio Initialization and Operation
98
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
9. Managing Power
9.1
Introduction
The WirelessUSB™ product family has been designed primarily for systems in which one node in the system is externally powered, and the other node or nodes are powered by
batteries. The externally powered node (the Master) is
therefore not particularly power sensitive, whereas minimizing power usage in the other nodes (the Slaves) is an important objective.
Many wireless networking solutions, particularly Frequency
Hopping Spread Spectrum (FHSS) systems, require tight
synchronization between nodes, resulting in a requirement
for all nodes to use highly accurate oscillators, and to keep
those oscillators running even when a node is not transmitting or receiving data. The WirelessUSB example protocols
provided by Cypress have no such requirement, and are
therefore able to achieve significantly lower average operating currents than synchronized systems.
Minimizing power consumption in WirelessUSB systems,
and in particular battery powered slave devices, requires
attention to a combination of system design and detailed
firmware design considerations.
At a system level, the design should minimize the number of
bits sent across the air, not necessarily in a single short
interval of time, but overall across the life of the batteries.
At a detail level, the design should be optimized so that the
Slave radio spends the minimum possible time in the high
power modes, and the maximum possible time in Sleep
mode, within the constraints imposed by the latency and
throughput requirements of the system.
9.2
Power Advantages of DSSS
By taking advantage of the coding gain inherent in Direct
Sequence Spread Spectrum (DSSS) systems, WirelessUSB
systems achieve a very low Packet Error Rate (PER).
Because retransmission on packet error is rare in WirelessUSB systems, the impact of occasional retransmissions on
overall power consumption is minimal.
On the other hand, typical FSK and FHSS radio systems are
subject to significant Bit Error Rates (BER), even in low
interference environments. This necessitates frequent
retransmission of data packets unless complex bandwidth
consuming error correction schemes such as FEC are
employed. Unless FEC is employed, the retransmission rate
in an FSK system must be factored into power consumption
calculations, and if so, the redundant data overhead needs
to be considered. Packet error rates exceeding 10% are not
uncommon in ISM band FSK radio systems, even in a low
interference environment. In the high interference environment commonly found in the 2.4 GHz ISM band, retransmission rates of 50% or more have been observed in simple
FSK radio systems.
The DSSS modulation of WirelessUSB enables reception of
data packets with almost zero BER, even in environments
where the error rate present in the raw symbols received is
as high as 10%[1]. This is equivalent to an improvement in
receive sensitivity and interference rejection of approximately 7 dB.
This chapter describes the various power saving modes of
WirelessUSB (hereafter referred to as ‘the Radio’), and
methods of using those modes to minimize power consumption in slave devices.
1. The relationship between BER and raw symbol (‘chip’) error rate (CER) is
a function of the length of the spreading code and the receiver correlator
thresholds selected.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
99
Managing Power
9.3
General Principles
longer than absolutely required. The example protocol
firmware is designed to be readily understood and readily ported for use on other processors and in a wide variety of applications. Designers seeking to minimize power
consumption in their application should customize the
firmware for their own specific processor and application, so that it is optimized for power, paying particular
attention to speed of firmware execution at the end of
transmit and receive processing.
System design considerations play a key role in minimizing
power consumption and therefore maximizing battery life in
WirelessUSB slave designs.
In most cases, designers building WirelessUSB products
and systems should be guided by the following principles:
■
■
■
■
■
Transmit larger packets, less often. Although small by
comparison with most networking protocols, WirelessUSB systems have a protocol overhead associated
with transmitting a data packet. Therefore, transmitting
two packets, each containing n bits of data takes more
time in a high power mode, and therefore consumes
more power overall than transmitting one packet containing 2n bits. Consequently, to the maximum extent
consistent with the latency requirements of the system,
designers should seek to transmit data in the largest
possible packets, and as infrequently as possible[2].
Send the minimum amount of data. Many ‘wired’ protocols have unused or rarely changing data fields. One
example of this is a typical USB keyboard report. This
contains eight bytes, only one or two of which are nonzero in the vast majority of transmissions. To optimize
power, wherever possible, designers should only send
data that has changed, and avoid sending unchanged
status data. In the keyboard example, this may cause
the designer to use variable length packets, and only
make a transmission when a new key was pressed or
released. This packet may contain only data about the
new key, rather than the state of other keys which had
not changed since the last event.
Compress data when possible. Many data fields in transmitted data packets are commonly encoded in such a
way that more bits are transmitted than necessary. For
example, information about the state of 16 flags is often
transmitted as 16 bits, even though only a small number
of flag setting combinations are valid. Power consumption can be minimized by transmitting the data values
encoded into the smallest possible number of bits, which
can then be decoded (for example using a lookup table)
by the receiver.
Leverage DSSS advantages. Designers familiar with
simple ISM FSK radio systems may be accustomed to
employing the error correction and/or detection encoding
schemes with the substantial overhead necessary in
such designs. However, because data errors (rather
than erasures) are highly improbable in WirelessUSB
systems, such schemes are unnecessary when using
WirelessUSB. The payload data in a WirelessUSB data
packet should simply be the data that needs to be transferred, unmodified by any redundant data encoding.
Sweat the small stuff. Optimize firmware to ensure that
the Radio is not in a high power mode for a microsecond
9.4
WirelessUSB Power Saving
Modes
WirelessUSB devices have five main operating modes:
■
Transmitting
■
Receiving
■
Synthesizer Settling
■
Idle
■
Power Down (also known as Sleep)
The power consumption values for these five modes can be
found in the data sheet, see Cypress Semiconductor Support on page 9.
The Idle and Sleep modes offer the lowest current consumption, and are therefore together referred to as the power saving modes. In order to minimize power consumption in a
WirelessUSB product the designer should seek to operate
the WirelessUSB IC in these modes except when actively
transmitting or receiving.
As there are timing considerations involved in transitioning
between the operating modes of WirelessUSB devices, minimizing power consumption involves making careful tradeoffs between the mode in use at a particular time, and the
latency of data transmitted.
9.5
Two-Way System Overview
In a typical WirelessUSB system, ‘the Master’ is normally
configured in receive mode, and ‘the Slave’ is normally in
one of the power saving modes.
When the Slave is ready to transmit, it transitions from the
low power mode into transmit mode, and sends data. After
sending data, it transitions to receive mode, receives a
handshake packet from the Master, and then transitions
back into a power saving mode until the next transmission.
(This process is described in more detail in the next section).
When the Master receives data, it waits for the end of the
packet, and then transitions into transmit mode, transmits a
handshake packet, and then immediately transitions back
into receive mode, and waits for the next data packet.
This process is deliberately designed to minimize the power
consumed by the Slaves, by shifting the power burden onto
2. The maximum payload length is 40 bytes.
100
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Managing Power
the Master, which is typically not particularly power sensitive.
1. Between transmissions, the Radio is in sleep mode, with
its oscillator stopped.
In some applications, the flow of data is from the Master to
the Slaves; this can be accommodated using a variant of the
procedure described above. In this case, rather than sending a data packet, the Slave device periodically polls the
Master by sending a short ‘Data Request’ packet. If no data
is available to send to the Slave, the Master responds with
the standard handshake packet and when it receives this,
the Slave transitions back into sleep mode. If data is available for the Slave, the Master transmits that data and then
waits for a handshake from the Slave. When the Slave
receives a data packet, it transmits a handshake packet
back to the Master if the data is correctly received. If the
data packet is not correctly received, no handshake packet
is transmitted (or a NAK packet is transmitted), causing the
Master to retransmit the data packet, ensuring that there is
no loss of data.
2. When the Microcontroller (MCU) in the Slave needs to
send data, it first sets the TX_GO bit in the
TX_CTRL_ADR register. This causes the Radio to enter
transaction mode. Transaction mode first instructs the
oscillator to start. While the oscillator starts the MCU
loads the TX_BUFFER_ADR with the desired payload
data.
9.6
Data Transmission Process
3. When the oscillator has stabilized to within 10 ppm of its
final value, the synthesizer automatically starts.
4. When the synthesizer has settled, the transmitter automatically starts.
5. When the transmit completes, the Radio automatically
transitions from transmit mode to receive mode in order
to receive the ACK packet.
6. When the ACK packet completes, the Radio must briefly
transition to idle mode.
7. The MCU may then configure the Radio to transition to
sleep mode.
In two-way WirelessUSB systems, the Slave node typically
follows the following procedure in order to transmit data:
Figure 9-1. Packet Transmission Process
4
26m A
5
21m A
3
8m A
2
R a d io Ic c
1
7
6
1m A
10uA
10uA
R a d io
MCU
OS
Tx
Go
Tx
Rx
Tx
Load
Figure 9-1 illustrates this process together with an indication
of current consumption of the Radio at each stage[3].
This process is implemented in its entirety by the example
protocols provided by Cypress. Designers choosing to use
the protocols unmodified do not need to create firmware to
perform this process. However, understanding of the pro-
3.
SS
S ta tu s
cess is important in managing power in WirelessUSB systems even when using the provided protocols unmodified.
9.7
Timing Considerations
WirelessUSB may be used in a wide variety of systems.
Applications such as wireless sensors may require occasional low latency transmission of a small amount of data.
Wireless HID applications may require the frequent trans-
Refer to the data sheet for precise values, see Cypress Semiconductor
Support on page 9.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
101
Managing Power
mission of data when the device is in use, but no transmissions for periods of hours or days when it is not.
In order to manage power most effectively in WirelessUSB
systems, it is therefore necessary to understand the timing
of transitions between the various operating modes, as well
as the current consumption in each mode.
The timing values for these transitions may be found in the
data sheet, see Cypress Semiconductor Support on page 9 .
9.8
Wakeup Timing
The wake time (oscillator stable) is influenced by two main
factors – the Equivalent Series Resistance (ESR) of the
crystal, and the capacitance with which the crystal has been
designed to operate.
The wakeup times specified in the data sheet are for a 60
ohm ESR crystal, designed to work with a 10 pF load.
9.9
Synthesizer Start Timing
The time taken for the synthesizer to lock is variable,
depending on the channel and whether or not the automatic
calibration procedure needs to execute. An automatic calibration procedure is triggered after each write operation to
the CHANNEL_ADR register. This procedure extends the
next settling time, while subsequent settling times depends
only on the channel used: 100 µs (fast), 180 µs (medium),
and 270 µs (slow).
9.10
Preamble Timing
Before transmitting data, the Radio transmits a preamble, in
order to assist the receiver in locking on to the transmitted
radio signal. In the presence of other RF energy at the
receiver (for example caused by other 2.4 GHz radio systems operating in the same area), 16 µs of preamble may
occasionally be insufficient for the receiving radio to lock to
the incoming WirelessUSB signal before the first data bit is
transmitted.
The designer has a couple of options for dealing with this situation:
■
Extend the pre-amble length by increasing the preamble
length field in the PREAMBLE_ADR register. This is the
least power-effective solution.
■
Let retransmission take care of the error. The checksum
enables any packet with a missing first bit to be detected
as being in error, and the Master therefore does not send
an ACK handshake. Consequently, the Slave retransmits the data packet. As the retransmission rate caused
by this effect is typically around 0.3%, the additional time
spent in higher power modes is less if 0.3% of packets
are retransmitted than if all packets are extended by 16
µs of additional pre-amble.
102
For the most power-effective solution, aggressive applications may configure the preamble symbol length to ‘1’ (16
µs) or even ‘0’, if so desired.
9.11
Transmit and Receive Mode
Timing
The Transmit and Receive modes are the highest power
modes of the devices. Microcontroller firmware should
therefore pay particular attention to spending the least possible amount of time in these modes, when in power-sensitive applications.
In order to minimize the amount of time spent in Transmit
and Receive modes, it is recommended that full use is made
of the Auto-ACK feature.
9.12
Debugging Tips
Even using an In-Circuit Emulator (ICE) and/or a logic analyzer connected to the SPI bus, it may not be possible to
readily observe the power mode that the Radio is in during
packet transmission, and therefore verifying that the timing
is optimized may not be straightforward.
As the performance of any radio may be affected by ripple or
noise on the Vcc supply to the IC, it is common design practice to minimize ripple and power supply noise at the radio
by placing a small resistor (for example, 1 ohm) in series
between the Radio IC Vcc and the power supply to the rest
of the circuit. This is valid for WirelessUSB Radios as well as
for any other radio system[4]. During debugging, this resistor
can be used as a current sensing resistor, which can give a
valuable real-time indication of the Radio operation. By connecting an isolated oscilloscope probe across the resistor,
the current being consumed by the Radio can be observed.
In the case of a 1 ohm resistor, each mV on the trace is
equivalent to 1 mA of current consumption.
The designer can use this technique to analyze the amount
of time the Radio spends in each mode during a data transmission, and verify that it is optimized to minimize overall
power consumption.
4. It is generally not recommended that an inductor be used for this
purpose in WirelessUSB applications, because the large changes
in Radio current between the low and high power modes may
cause ringing in the radio Vcc at the resonant frequency of the
inductor and decoupling capacitors in response to step changes
in the current the Radio is drawing.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
10. Registers
10.1
Introduction
This section describes the WirelessUSB LP/LPstar registers. The registers are named according to the following conventions.
The general register format is XXX_nnn_ADR, where:
XXX_
is the operation.
nnn_
is the type.
■
LENGTH, is the length of the data in either the transmit or receive buffers.
■
CTRL, is a control register.
■
CFG, is a configuration register.
■
STATUS, is a status register.
■
THOLD, is a PN Code threshold register.
_ADR
10.1.1
■
is the suffix to uniquely identify all radio registers.
Example Register Formats
TX_LENGTH_ADR is the length of the transmit data packet.
10.1.2
Other Conventions
EN
Means enable.
OP
Means output.
IP
Means input.
VAL
Means valid.
IRQEN Means interrupt request enable.
This chapter is a reference for all the WirelessUSB LP/LPstar device registers in address order.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
103
Registers
10.2
Maneuvering Around the Registers
For ease-of-use, this chapter has been formatted so that there is one register per page, although some registers use two
pages. On each page, from top to bottom, there are four sections:
1. Register name and address (from lowest to highest).
2. Register table showing the bit organization, with reserved bits grayed out.
3. Written description of register specifics or links to additional register information.
4. Detailed register bit descriptions.
10.2.1
Accessing Registers
All registers must be configured or accessed when the radio is in idle or sleep mode. Registers cannot be accessed during
active transmit or receive modes.
However, the following registers can be configured or accessed during active transmit or receive mode.
■
PWR_CTRL_ADR
0X0B
■
IO_CFG_ADR
0x0D
■
GPIO_CTRL_ADR
0x0E
■
RSSI_ADR
0x13
10.3
Register Conventions
The following table lists the register conventions that are specific to this chapter.
Table 10-1. Register Conventions
Convention
Example
Description
‘x’ in a register name
ACBxxCR1
Multiple instances/address ranges of the same register
R
R : 00
Read register or bit(s)
W
W : 00
Write register or bit(s)
L
RL : 00
Logical register or bit(s)
C
RC : 00
Clearable register or bit(s)
00
RW : 00
Reset value is 0x00 or 00h
XX
RW : XX
Register is not reset
0,
0,04h
Register is in bank 0
1,
1,23h
Register is in bank 1
x,
x,F7h
Register exists in register bank 0 and register bank 1
Empty, grayed-out
table cell
104
‘Not Used’ bit or group of bits, unless otherwise stated
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Registers
10.4
Register Descriptions
All registers are read and writable, except where noted. Registers may be written to or read from either individually or in
sequential groups.
Table 10-2. Register Map Summary
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11
0x12
0x13
0x14
0x15
0x16
0x17
0x18
0x19
0x1A
0x1B
0x1C
0x1D
0x1E
0x1F
0x26
0x27
0x28
0x29
0x32
0x35
0x39
Register Files
0x20
0x21
CHANNEL_ADR
TX_LENGTH_ADR
TX_CTRL_ADR
TX_CFG_ADR
TX_IRQ_STATUS_ADR
RX_CTRL_ADR
RX_CFG_ADR
RX_IRQ_STATUS_ADR
RX_STATUS_ADR
RX_COUNT_ADR
RX_LENGTH_ADR
PWR_CTRL_ADR
XTAL_CTRL_ADR
IO_CFG_ADR
GPIO_CTRL_ADR
XACT_CFG_ADR
FRAMING_CFG_ADR
DATA32_THOLD_ADR
DATA64_THOLD_ADR
RSSI_ADR
EOP_CTRL_ADR
CRC_SEED_LSB_ADR
CRC_SEED_MSB_ADR
TX_CRC_LSB_ADR
TX_CRC_MSB_ADR
RX_CRC_LSB_ADR
RX_CRC_MSB_ADR
TX_OFFSET_LSB_ADR
TX_OFFSET_MSB_ADR
MODE_OVERRIDE_ADR
RX_OVERRIDE_ADR
TX_OVERRIDE_ADR
XTAL_CFG_ADR
CLK_OFFSET_ADR
CLK_EN_ADR
RX_ABORT_ADR
AUTO_CAL_TIME_ADR
AUTO_CAL_OFFSET_ADR
ANALOG_CTRL_ADR
Access by Bit[1]
-bbbbbbb
bbbbbbbb
bbbbbbbb
--bbbbbb
rrrrrrrr
bbbbbbbb
bbbbb-bb
brrrrrrr
rrrrrrrr
rrrrrrrr
rrrrrrrr
bbb-bbbb
bbb--bbb
bbbbbbbb
bbbbrrrr
b-bbbbbb
bbbbbbbb
----bbbb
---bbbbb
r-rrrrrr
bbbbbbbb
bbbbbbbb
bbbbbbbb
rrrrrrrr
rrrrrrrr
rrrrrrrr
rrrrrrrr
bbbbbbbb
----bbbb
wwwww--w
bbbbbbbbbbbbbbb
wwwwwwww
wwwwwwww
wwwwwwww
wwwwwwww
wwwwwwww
wwwwwwww
wwwwwwww
TX_BUFFER_ADR
RX_BUFFER_ADR
wwwwwwww
rrrrrrrr
W
R
148
149
0x22
SOP_CODE_ADR[2]
bbbbbbbb
RW
150
0x23
DATA_CODE_ADR[3]
bbbbbbbb
RW
151
0x24
PREAMBLE_ADR[4]
MFG_ID_ADR
bbbbbbbb
RW
152
rrrrrrrr
R
153
Address
0x25
Mnemonic
Access
Page
RW
RW
RW
RW
R
RW
RW
RW
R
R
R
RW
RW
RW
RW
RW
RW
RW
RW
R
RW
RW
RW
R
R
R
R
RW
RW
W
RW
RW
W
W
W
W
W
W
W
106
107
108
109
110
113
114
115
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
Notes
1. b = read/write; r = read only; w = write only; ‘-’ = not used, default value is undefined.
2. SOP_CODE_ADR default = 0x17FF9E213690C782.
3. DATA_CODE_ADR default = 0x02F9939702FA5CE3012BF1DB0132BE6F.
4. PREAMBLE_ADR default = 0x333302.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
105
0x00h
10.5
Register Details and Examples
The registers that follow are described in detail and listed one register per page.
10.5.1
CHANNEL_ADR
Channel Register
Individual Register Names and Addresses:
CHANNEL_ADR
Access : POR
0x00h
7
6
5
4
3
2
1
0
R/W:x
R/W:1
R/W:0
R/W:0
R/W:1
R/W:0
R/W:0
R/W:0
Channel
Bit Name
Bit
Name
Description
6:0
Channel
This field selects the channel. 0x00 sets 2400 MHz; 0x62 sets 2498 MHz. Values above 0x62 are not
valid. The default channel is a fast channel above the frequency typically used in non-overlapping
WiFi systems. Any write to this register impacts the time it takes the synthesizer to settle.
fast (100 s) - 0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 96
medium (180 s) - 2 4 8 10 14 16 20 22 26 28 32 34 38 40 44 46 50 52 56 58 62 64 68 70 74 76 78 80 82 84 86 88 90 92 94
slow (270 s) - 1 5 7 11 13 17 19 23 25 29 31 35 37 41 43 47 49 53 55 59 61 65 67 71 73 75 77 79 81 83 85 87 89 91 93 95 97
Note: Usable channels subject to regulation.
106
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x01h
10.5.2
TX_LENGTH_ADR
Transmit Length Address Register
Individual Register Names and Addresses:
TX_LENGTH_ADR 0x01h
Access : POR
7
6
5
4
R/W:0
R/W:0
R/W:0
R/W:0
3
2
1
0
R/W:0
R/W:0
R/W:0
R/W:0
TX Length
Bit Name
Bit
Name
Description
7:0
TX Length
This register sets the length of the packet to be transmitted. A length of zero is valid, and a packet
with SOP, length, and CRC16 fields (if enabled) is transmitted, but no data field. Packet lengths of
more than 16 bytes require that some data bytes be written after transmission of the packet has
begun. Typically, length is updated prior to setting TX GO. The maximum packet length for all packets
is 40 bytes except for framed 64-chip DDR where the maximum packet length is 16 bytes.
Note: Maximum packet length is limited by the delta between the transmitter and receiver crystals of 60 ppm or better.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
107
0x02h
10.5.3
TX_CTRL_ADR
Transmit Control Address Register
Individual Register Names and Addresses:
TX_CTRL_ADR
0x02h
7
6
5
4
3
2
1
0
Access : POR
R/W:0
R/W:0
R/W:
R/W:0
R/W:0
R/W:0
R/W:1
R/W:1
TX GO
TX CLR
TXB15
IRQEN
TXB8
IRQEN
TXB0
IRQEN
TXBERR
IRQEN
TXC
IRQEN
TXE
IRQEN
Bit Name
Bit
Name
Description
7
TX GO
Start Transmission. Setting this bit triggers the transmission of a packet. Writing a 0 to this flag has no
effect. This bit is cleared automatically at the end of packet transmission. The transmit buffer may be
loaded either before or after setting this bit. If data is loaded after setting this bit, the length of time
available to load the buffer depends on the starting state (sleep, idle or synth), the length of the SOP
code, the length of preamble, and the packet data rate. For example, if starting from idle mode on a
fast channel in 8DR mode with 32-chip SOP codes, the time available is 100 s (synth start) + 32 s
(preamble) + 64 s (SOP length) + 32 s (length byte) = 228 s. If there are no bytes in the TX buffer
at the end of transmission of the length field, a TXBERR IRQ occurs and transmission aborts.
6
TX CLR
Clear TX Buffer. Writing a 1 to this register clears the transmit buffer. Writing a 0 to this bit has no
effect. The previous packet (16 bytes or fewer) may be retransmitted by setting TX GO and not setting this bit. A new transmit packet may be loaded and transmitted without setting this bit if TX GO is
set after the new packet is loaded to the buffer. If a new transmit packet is to be loaded before/after
the TX GO bit has been set, then this bit should be set before loading a new transmit packet to the
buffer.
5
TXB15 IRQEN
Buffer Not Full Interrupt Enable. See section 10.5.5 TX_IRQ_STATUS_ADR on page 110 for description.
4
TXB8 IRQEN
Buffer Half Empty Interrupt Enable. See section 10.5.5 TX_IRQ_STATUS_ADR on page 110 for
description.
3
TXB0 IRQEN
Buffer Empty Interrupt Enable. See section 10.5.5 TX_IRQ_STATUS_ADR on page 110 for description.
2
TXBERR IRQEN
Buffer Error Interrupt Enable. See section 10.5.5 TX_IRQ_STATUS_ADR on page 110 for description.
1
TXC IRQEN
Transmission Complete Interrupt Enable. See section 10.5.5 TX_IRQ_STATUS_ADR on page 110
for description. TXC IRQEN and TXE IRQEN must be set together.
0
TXE IRQEN
Transmit Error Interrupt Enable. See section 10.5.5 TX_IRQ_STATUS_ADR on page 110 for description. TXC IRQEN and TXE IRQEN must be set together.
108
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x03h
10.5.4
TX_CFG_ADR
Register
Individual Register Names and Addresses:
TX_CFG_ADR:
0x03h
LP
7
6
Access : POR
R/W:x
R/W:x
Bit Name
5
4
R/W:0
R/W:0
Data Code Length
3
2
R/W:0
R/W:1
Data Mode
1
0
R/W:0
R/W:1
PA Setting
LPstar
7
6
5
4
3
2
1
0
Access : POR
R/W:x
R/W:x
R/W:0
R/W:0
R/W:0
R/W:1
R/W:0
R/W:1
Data Code Length
RSVD
Data Mode
Bit Name
PA Setting
Bit
Name
Description
5
Data Code Length
Data Code Length. This bit selects the length of the DATA_CODE_ADR code for the data portion of
the packet. This bit is ignored when the data mode is set to GFSK.
1 = 64-chip codes
0 = 32-chip codes
4:3
Data Mode
Data Mode. This field sets the data transmission mode. For LPstar, only bit 3 is used.
00 = 1-Mbps GFSK.
01 = 8DR Mode
10 = DDR Mode
11 = SDR Mode.
It is recommended that firmware sets the ALL SLOW bit in register ANALOG_CTRL_ADR when
using GFSK data rate mode.
2:0
PA Setting
PA Setting. This field sets the transmit signal strength. For LPstar, the max set is 6= 0 dBm.
0 = –35 dBm
1 = –30 dBm
2 = –24 dBm
3 = –18 dBm
4 = –13 dBm
5 = –5 dBm
6 = 0 dBm
7 = +4 dBm
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
109
0x04h
10.5.5
TX_IRQ_STATUS_ADR
Register
Individual Register Names and Addresses:
TX_IRQ_STATUS_ADR
0x04h
LP
7
6
5
4
3
2
1
0
Access : POR
R/W:1
R/W:0
R/W:1
R/W:1
R/W:1
R/W:0
R/W:0
R/W:0
OS IRQ
LV IRQ
TXB15 IRQ
TXB8 IRQ
TXB0 IRQ
TXBERR IRQ
TXC IRQ
TXE IRQ
Bit Name
The state of all IRQ status bits is valid regardless of whether or not the IRQ is enabled. The IRQ output of the device is in its
active state whenever one or more bits in this register is set and the corresponding IRQ enable bit is also set. Status bits are
non-atomic (different flags may change value at different times in response to a single event).
.
LPstar
7
6
5
4
3
2
1
0
Access : POR
R/W:1
R/W:0
R/W:1
R/W:1
R/W:1
R/W:0
R/W:0
R/W:0
OS IRQ
RSVD
TXB15 IRQ
TXB8 IRQ
TXB0 IRQ
TXBERR IRQ
TXC IRQ
TXE IRQ
Bit Name
Bit
Name
Description
7
OS IRQ
Oscillator Stable IRQ Status. This bit is set when the internal crystal oscillator has settled (synthesizer
sequence starts).
6
LV IRQ
Low Voltage Interrupt Status. This bit is set when the voltage on VBAT is below the LVI threshold (see
“PWR_CTRL_ADR” on page 119). This interrupt is automatically disabled whenever the PMU is disabled. When enabled, this bit reflects the voltage on VBAT.
For LPstar, this bit is RSVD.
5
TXB15 IRQ
Buffer Not Full Interrupt Status. This bit is set whenever there are 15 or fewer bytes remaining in the
transmit buffer.
4
TXB8 IRQ
Buffer Half Empty Interrupt Status. This bit is set whenever there are eight or fewer bytes remaining in
the transmit buffer.
3
TXB0 IRQ
Buffer Empty Interrupt Status. This bit is set at any time the transmit buffer is empty.
2
TXBERR IRQ
Buffer Error Interrupt Status. This IRQ is triggered by either of two events: (1) When the transmit buffer (TX_BUFFER_ADR) is empty and the number of bytes remaining to be transmitted is greater than
zero. (2) When a byte is written to the transmit buffer and the buffer is already full. This IRQ is cleared
by setting bit the TX CLR in TX_CTRL_ADR.
1
TXC IRQ
Transmission Complete Interrupt Status. This IRQ is triggered when transmission is complete. If
transaction mode is not enabled, then this interrupt is triggered immediately after transmission of the
last bit of the CRC16. If transaction mode is enabled, this interrupt is triggered at the end of a transaction. Reading this register clears this bit. TXC IRQ and TXE IRQ flags may change value at different
times in response to a single event. If transaction mode is enabled and the first read of this register
returns TXC IRQ=1 and TXE IRQ=0, then firmware must execute a second read to this register to
determine if an error occurred by examining the status of TXE. There can be a case when this bit is
not triggered when ACK EN = 1 and there is an error in transmission. If the first read of this register
returns TXC IRQ = 1 and TXE IRQ = 1, then the firmware must not execute a second read to this reg-
110
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x04h
ister for a given transaction. If an ACK is received, RXC IRQ and RXE IRQ may be asserted instead
of TXC IRQ and TXE IRQ.
0
TXE IRQ
Transmit Error Interrupt Status. This IRQ is triggered when there is an error in transmission. This
interrupt is only applicable to transaction mode. It is triggered whenever no valid ACK packet is
received within the ACK timeout period. Reading this register clears this bit.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
111
0x05h
10.5.6
RX_CTRL_ADR
Register
Individual Register Names and Addresses:
RX_CTRL_ADR :
Access : POR
Bit Name
0x05h
7
6
5
4
3
2
1
0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:1
R/W:1
R/W:1
RX GO
RSVD
RXB16
IRQEN
RXB8
IRQEN
RXB1
IRQEN
RXBERR
IRQEN
RXC
IRQEN
RXE
IRQEN
Bit
Name
Description
7
RX GO
Start Receive. Setting this bit causes the device to transition to receive mode. If necessary, the crystal oscillator and synthesizer start automatically after this bit is set. Firmware must never clear this bit.
This bit must not be set until after it self clears. The recommended method to exit receive mode when
an error has occurred is to force END STATE and then dummy read all RX_COUNT_ADR bytes from
RX_BUFFER_ADR or poll RSSI_ADR.SOP (bit 7) until set. See “XACT_CFG_ADR” on page 124
and “RX_ABORT_ADR” on page 144 for description.
6
RSVD
Reserved. Must be zero.
5
RXB16 IRQEN
Buffer Full Interrupt Enable. See “RX_IRQ_STATUS_ADR” on page 115 for description.
4
RXB8 IRQEN
Buffer Half Empty Interrupt Enable. See “RX_IRQ_STATUS_ADR” on page 115 for description.
3
RXB1 IRQEN
Buffer Not Empty Interrupt Enable. See“RX_IRQ_STATUS_ADR” on page 115 for description.
2
RXBERR IRQEN
Buffer Error Interrupt Enable. See “RX_IRQ_STATUS_ADR” on page 115 for description.
1
RXC IRQEN
Packet Reception Complete Interrupt Enable. See“RX_IRQ_STATUS_ADR” on page 115 for description.
0
RXE IRQEN
Receive Error Interrupt Enable. See“RX_IRQ_STATUS_ADR” on page 115 for description.
112
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x06h
10.5.7
RX_CFG_ADR
Register
Individual Register Names and Addresses:
RX_CFG_ADR :
Access : POR
Bit Name
0x06h
7
6
5
4
3
2
1
0
R/W:1
R/W:0
R/W:0
R/W:1
R/W:0
R/W:x
R/W:R/W:1
0
AGC EN
LNA
ATT
HILO
FAST TURN
EN
RXOW EN
VLD EN
Status bits are non-atomic (different flags may change value at different times in response to a single event).
Bit
Name
Description
7
AGC EN
Automatic Gain Control (AGC) Enable. When this bit is set, AGC is enabled, and the LNA is controlled by the AGC circuit. When this bit is cleared, the LNA is controlled manually using the LNA bit.
Typical applications clear this bit during initialization. It is recommended that this bit be disabled and
bit 6 (LNA) be enabled unless the device is used in a system where it may receive data from a device
using an external PA to transmit signals at >+4 dBm.
6
LNA
Low Noise Amplifier (LNA) Manual Control. When AGC EN (Bit 7) is cleared, this bit controls the state
of the receiver LNA; when AGC EN is set, this bit has no effect. Setting this bit enables the LNA;
clearing this bit disables the LNA. Device current in receive mode is slightly lower when the LNA is
disabled. Typical applications set this bit during initialization.
5
ATT
Receive Attenuator Enable. Setting this bit enables the receiver attenuator. The receiver attenuator
may be used to de-sensitize the receiver so that only very strong signals may be received. This bit
should only be set when the AGC EN is disabled and the LNA is manually disabled.
4
HILO
HILO. When FAST TURN EN is set, this bit is used to select whether the device uses the high frequency for the channel selected, or the low frequency: 1 = high; 0 = low. When FAST TURN EN is not
enabled this also controls the HILO bit to the receiver and must be left at the default value of ‘1’ for
high side receive injection. Typical applications clear this bit during initialization.
3
FAST TURN EN
Fast Turn Mode Enable. When this bit is set, the HILO bit determines whether the device receives
data transmitted 1 MHz above the RX Synthesizer frequency or 1 MHz below the receiver synthesizer
frequency. Use of this mode allows for very fast turn-around, because the same synthesizer frequency may be used for both transmit and receive, thus eliminating the synthesizer re-settling period
between transmit and receive. Note that when this bit is set, and the HILO bit is cleared, received
data bits are automatically inverted to compensate for the inversion of data received on the ‘image’
frequency. Typical applications set this bit during initialization.
1
RXOW EN
Overwrite Enable. When this bit is set, if an SOP is detected while the receive buffer is not empty,
then the existing contents of receive buffer are lost, and the new packet is loaded into the receive buffer. When this bit is set, the RXOW IRQ is enabled. If this bit is cleared, then the receive buffer may
not be over-written by a new packet, and whenever the receive buffer is not empty SOP conditions
are ignored, and it is not possible to receive data until the previously received packet has been completely read from the receive buffer.
0
VLD EN
Valid Flag Enable. When this bit is set, the receive buffer can store only eight bytes of data interleaved with valids (data0, valids0, data1, valids1,...). Typically, this bit is set only when interoperability
with first generation devices is desired. See “RX_BUFFER_ADR” on page 149 for more detail.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
113
0x07h
10.5.8
RX_IRQ_STATUS_ADR
Register
Individual Register Names and Addresses:
RX_IRQ_STATUS_ADR : 0x07h
Access : POR
Bit Name
7
6
5
4
3
2
1
0
R/W:x
R:x
R:x
R:x
R:x
R:x
R:x
R:x
RXOW IRQ
SOPDET IRQ
RXB16 IRQ
RXB8 IRQ
RXB1 IRQ
RXBERR IRQ
RXC IRQ
RXE IRQ
The state of all IRQ Status bits is valid regardless of whether or not the IRQ is enabled. The IRQ output of the device is in its
active state whenever one or more bits in this register is set and the corresponding IRQ enable bit is also set. Status bits are
non-atomic (different flags may change value at different times in response to a single event).
Bit
Name
Description
7
RXOW IRQ
Receive Overwrite Interrupt Status. This IRQ is triggered when the receive buffer is over-written by a
packet being received before the previous packet has been read from the buffer. This bit is cleared by
writing any value to this register. This condition is only possible when the RXOW EN bit in
RX_CFG_ADR is set. This bit must be written ‘1’ by firmware before the new packet may be read
from the receive buffer.
6
SOPDET IRQ
Start of packet detect. This bit is set whenever the start of packet symbol is detected.
5
RXB16 IRQ
Receive Buffer Full Interrupt Status. This bit is set whenever the receive buffer is full, and cleared otherwise.
4
RXB8 IRQ
Receive Buffer Half Full Interrupt Status. This bit is set whenever there are eight or more bytes
remaining in the receive buffer. Firmware must read exactly eight bytes when reading RXB8 IRQ.
3
RXB1 IRQ
Receive Buffer Not Empty Interrupt Status. This bit is set at any time that there are one or more bytes
in the receive buffer, and cleared when the receive buffer is empty. It is possible, in rare cases, that
the last byte of a packet may remain in the buffer even though the RXB1_IRQ flag has cleared. This
can ONLY happen on the last byte of a packet and only if the packet data is being read out of the buffer while the packet is still being received. The flag is trustworthy under all other conditions, and for all
bytes prior to the last. When using RXB1_IRQ and unloading the packet data during reception, the
user should be sure to check the RX_COUNT_ADR value after the RXC IRQ/RXE IRQ is set and
unload the last remaining byte if the number of bytes unloaded is less than the reported count, even
though the RXB1_IRQ is not set.
2
RXBERR IRQ
Receive Buffer Error Interrupt Status. This IRQ is triggered in one of two ways: (1) When the receive
buffer is empty and there is an attempt to read data. (2) When the receive buffer is full and more data
is received. This flag is cleared when RX GO is set and an SOP is received.
(continued on next page)
114
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x07h
10.5.8
RX_IRQ_STATUS_ADR (continued)
1
RXC IRQ
Packet Receive Complete Interrupt Status. This IRQ is triggered when a packet has been received. If
transaction mode is enabled, then this bit is not set until after transmission of the ACK. If transaction
mode is not enabled, then this bit is set as soon as a valid packet is received. This bit is cleared when
this register is read. RXC IRQ and RXE IRQ flags may change value at different times in response to
a single event. There are cases when this bit is not triggered when ACK EN = 1 and there is an error
in reception. Therefore, firmware should examine RXC IRQ, RXE IRQ, and CRC 0 to determine
receive status. If the first read of this register returns RXC IRQ = 1 and RXE IRQ = 0, then firmware
must execute a second read to this register to determine if an error occurred by examining the status
of RXE IRQ. If the first read of this register returns RXC IRQ = 1 and RXE IRQ = 1, then the firmware
must not execute a second read to this register for a given transaction.
0
RXE IRQ
Receive Error Interrupt Status. This IRQ is triggered when there is an error in reception. It is triggered
whenever a packet is received with a bad CRC16, an unexpected EOP is detected, a packet type
(data or ACK) mismatch, or a packet is dropped because the receive buffer is still not empty when the
next packet starts. The exact cause of the error may be determined by reading RX_STATUS_ADR.
This bit is cleared when this register is read.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
115
0x08h
10.5.9
RX_STATUS_ADR
Register
Individual Register Names and Addresses:
RX_STATUS_ADR :
.
7
6
5
4
3
2
R/W:0
R/W:0
R/W:0
R/W:0
R/W:1
R/W:x
R/W:x
RX ACK
PKT ERR
EOP ERR
CRC0
Bad CRC
RX Code
RX Data Mode
Access : POR
Bit Name
0x08h
1
0
It is expected that firmware does not read this register until after TX GO self clears. Status bits are non-atomic (different flags
may change value at different times in response to a single event).
Bit
Name
Description
7
RX ACK
RX Packet Type. This bit is set when the received packet is an ACK packet, and cleared when the
received packet is a standard packet.
6
PKT ERR
Receive Packet Type Error. This bit is set when the packet type received is what not was expected
and cleared when the packet type received was as expected. For example, if a data packet is
expected and an ACK is received, this bit is set.
5
EOP ERR
Unexpected EOP. This bit is set when an EOP is detected before the expected data length and
CRC16 fields have been received. This bit is cleared when SOP pattern for the next packet has been
received. This includes the case where there are invalid bits detected in the length field and the
length field is forced to 0.
4
CRC0
Zero-seed CRC16. This bit is set whenever the CRC16 of the last received packet has a zero seed.
3
Bad CRC
Bad CRC16. This bit is set when the CRC16 of the last received packet is incorrect.
2
RX Code
Receive Code Length. This bit indicates the DATA_CODE_ADR code length used in the last correctly
received packet.
1 = 64-chip code
0 = 32-chip code
1:0
RX Data Mode
Receive Data Mode. These bits indicate the data mode of the last correctly received packet.
00 = 1-Mbps GFSK
01 = 8DR
10 = DDR
11 = Not Valid
These bits do not apply to unframed packets.
116
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x09h
10.5.10
RX_COUNT_ADR
Register
Individual Register Names and Addresses:
RX_COUNT_ADR :
0x09h
7
6
5
Access : POR
4
3
2
1
0
R/W:0
Bit Name
RX Count
Count bits are non-atomic (updated at different times).
Bit
Name
Description
7:0
RX Count
This register contains the total number of payload bytes received during reception of the current
packet. After packet reception is complete, this register matches the value in RX_LENGTH_ADR
unless there was a packet error. This register is cleared when RX_LENGTH_ADR is automatically
loaded, if length is enabled, after the SOP. Count must not be read when RX_GO=1 during a transaction.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
117
0x0Ah
10.5.11
RX_LENGTH_ADR
Register
Individual Register Names and Addresses:
RX_LENGTH_ADR :
0x0Ah
7
6
5
Access : POR
4
3
2
1
0
R/W:0
Bit Name
RX Length
Length bits are non-atomic (different flags may change value at different times in response to a single event).
Bit
Name
Description
7:0
RX Length
This register contains the length field which is updated with the reception of a new length field (shortly
after start of packet detected). If there is an error in the received length field, 0x00 is loaded instead,
except when using GFSK data rate, and an error is flagged.
118
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x0Bh
10.5.12
PWR_CTRL_ADR
Register
Individual Register Names and Addresses:
PWR_CTRL_ADR :
0x0Bh
LP
7
Access : POR
Bit Name
6
5
4
3
2
1
0
R/W:1
R/W:0
R/W:1
R/W:x
R/W:0
R/W:0
PMU EN
LVIRQ EN
PMU SEN
PFET DIS
LVI TH
PMU OUTV
LPstar
7
6
5
4
Access : POR
R/W:1
R/W:0
R/W:1
R/W:x
Bit Name
3
2
R/W:0
1
0
R/W:0
The firmware should set “00010000” to this register while initiating
Bit
Name
Description
7
PMU EN
Power Management Unit (PMU) Enable. Setting this bit enables the PMU. When the PMU is disabled, or if the PMU is enabled and the VBAT voltage is above the value set in Bits 1:0 of this register,
the VREG pin is internally connected to the VBAT pin. if the PMU is enabled and the VBAT voltage is
below the value set by PMU OUTV, then the PMU boosts the VREG pin to a voltage not less than the
value set by PMUOP.
6
LVIRQ EN
Low Voltage Interrupt Enable. Setting this bit enables the LV IRQ interrupt. When this interrupt is
enabled, if the VBAT voltage falls below the threshold set by LVI TH, then a low voltage interrupt is
generated. The LVI is not available when the device is in sleep mode. The LVI event on IRQ pin is
automatically disabled whenever the PMU is disabled.
5
PMU SEN
PMU Sleep Mode Enable. If this bit is set, the PMU continues to operate normally when the device is
in sleep mode. If this bit is not set, then the PMU is disabled when the device is in sleep mode. In this
case, if VBAT is below the PMU OUTV voltage and PMU EN is set, when the device enters sleep
mode the VREG voltage falls to the VBAT voltage as the VREG capacitors discharge.
4
PFET DIS
Setting this bit to ‘1’ disables the FET, thereby safely allowing VBAT to be connected to a separate reference from Vcc when the PMU is disabled to the radio.
3:2
LVI TH
Low Voltage Interrupt Threshold. This field sets the voltage on VBAT at which the LVI is triggered.
11 = 1.8V
10 = 2.0V
01 = 2.2V
00 = PMU OUTV voltage
1:0
PMU OUTV
PMU Output Voltage. This field sets the minimum output voltage of the PMU.
11 = 2.4V
10 = 2.5V
01 = 2.6V
00 = 2.7V.
When the PMU is active, the voltage output by the PMU on VREG is never less than this voltage provided that the total load on the VREG pin is less than the specified maximum value, and the voltage in
VBAT is greater than the specified minimum value.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
119
0x0Ch
10.5.13
XTAL_CTRL_ADR
Register
Individual Register Names and Addresses:
XTAL_CTRL_ADR :
Access : POR
0x0Ch
7
6
5
R/W:0
R/W:0
R/W:0
Bit Name
XOUT FN
XSIRQ EN
4
3
R/W:x
2
1
0
R/W:1
R/W:0
R/W:0
FREQ
Bit
Name
Description
7:6
XOUT FN
XOUT Pin Function. This field selects between the different functions of the XOUT pin.
00 = Clock frequency set by XOUT FREQ
01 = Active LOW PA Control
10 = Radio data serial bit stream. If this option is selected and SPI is configured for 3-wire mode, then
the MISO pin outputs a serial clock associated with this data stream.
11 = GPIO. To disable this output, set to GPIO mode, and set the GPIO state in IO_CFG_ADR.
5
XSIRQ EN
Crystal Stable Interrupt Enable. This bit enables the OS IRQ interrupt. When enabled, this interrupt
generates an IRQ event when the crystal has stabilized after the device has woken from sleep mode.
This event is cleared by writing zero to this bit.
2:0
FREQ
XOUT Frequency. This field sets the frequency output on the XOUT pin when XOUT FN is set to 00.
0 = 12 MHz
1 = 6 MHz
2 = 3 MHz
3 = 1.5 MHz
4 = 0.75 MHz
Other values are not defined.
120
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x0Dh
10.5.14
IO_CFG_ADR
Register
Individual Register Names and Addresses:
IO_CFG_ADR :
0x0Dh
LP
7
Access : POR
Bit Name
6
5
4
3
2
1
0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
IRQ OD
IRQ POL
MISO OD
XOUT OD
PACTL OD
PACTL GPIO
SPI 3PIN
IRQ GPIO
To use a GPIO pin as an input, the output mode must be set to open drain, and a ‘1’ written to the corresponding output register bit.
LPstar
7
6
5
4
3
2
1
0
Access : POR
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
IRQ OD
IRQ POL
MISO OD
XOUT OD
RSVD
RSVD
SPI 3PIN
IRQ GPIO
Bit Name
Bit
Name
Description
7
IRQ OD
IRQ Pin Drive Strength. Setting this bit configures the IRQ pin as an open drain output. Clearing this
bit configures the IRQ pin as a standard CMOS output, with the output ‘1’ drive voltage being equal to
the VIO pin voltage.
6
IRQ POL
IRQ Polarity. Setting this bit configures the IRQ signal polarity to be active HIGH. Clearing this bit
configures the IRQ signal polarity to be active low.
5
MISO OD
MISO Pin Drive Strength. Setting this bit configures the MISO pin as an open drain output. Clearing
this bit configures the MISO pin as a standard CMOS output, with the output ‘1’ drive voltage being
equal to the VIO pin voltage.
4
XOUT OD
XOUT Pin Drive Strength. Setting this bit configures the XOUT pin as an open drain output. Clearing
this bit configures the XOUT pin as a standard CMOS output, with the output ‘1’ drive voltage being
equal to the VIO pin voltage.
3
PACTL OD
PACTL Pin Drive Strength. Setting this bit configures the PACTL pin as an open drain output. Clearing this bit configures the PACTL pin as a standard CMOS output, with the output ‘1’ drive voltage
being equal to the VIO pin voltage.
For LPstar, this bit is RSVD.
2
PACTL GPIO
PACTL Pin Function. When this bit is set the PACTL pin is available for use as a GPIO.
For LPstar, this bit is RSVD.
1
SPI 3PIN
SPI Mode. When this bit is cleared, the SPI interface acts as a standard 4-wire SPI Slave interface.
When this bit is set, the SPI interface operates in ‘3-Wire Mode’ combining MISO and MOSI on the
same pin (SDAT), and the MISO pin is available as a GPIO pin.
0
IRQ GPIO
IRQ Pin Function. When this bit is cleared, the IRQ pin is asserted when an IRQ is active; the polarity
of this IRQ signal is configurable in IRQ POL. When this bit is set, the IRQ pin is available for use as
a GPIO pin, and the IRQ function is multiplexed onto the MOSI pin. In this case the IRQ signal state
is presented on the MOSI pin whenever the SS signal is inactive (HIGH).
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
121
0x0Eh
10.5.15
GPIO_CTRL_ADR
Register
Individual Register Names and Addresses:
GPIO_CTRL_ADR :
0x0Eh
LP
7
6
5
4
3
2
1
0
Access : POR
RW:0
R/W:0
R/W:0
R/W:0
R:x
R:x
R:x
R:x
XOUT OP
MISO OP
PACTL OP
IRQ OP
XOUT IP
MISO IP
PACTL IP
IRQ IP
Bit Name
To use a GPIO pin as an input, the output mode must be set to open drain, and a ‘1’ written to the corresponding output register bit.
LPstar
7
6
5
4
3
2
1
0
Access : POR
RW:0
R/W:0
R/W:0
R/W:0
R:x
R:x
R:x
R:x
XOUT OP
MISO OP
RSVD
IRQ OP
XOUT IP
MISO IP
RSVD
IRQ IP
Bit Name
Bit
Name
Description
7
XOUT OP
XOUT Output. When the XOUT pin is configured to be a GPIO, the state of this bit sets the output
state of the XOUT pin.
6
MISO OP
MISO Output. When the MISO pin is configured to be a GPIO, the state of this bit sets the output
state of the MISO pin.
5
PACTL OP
PACTL Output. When the PACTL pin is configured to be a GPIO, the state of this bit sets the output
state of the PACTL pin.
For LPstar, this bit is RSVD.
4
IRQ OP
IRQ Output. When the IRQ pin is configured to be a GPIO, the state of this bit sets the output state of
the IRQ pin.
3
XOUT IP
XOUT Input. When the XOUT pin is configured to be a GPIO, the state of this bit reflects the voltage
on the XOUT pin.
2
MISO IP
MISO Input. When the MISO pin is configured to be a GPIO, the state of this bit reflects the voltage
on the MISO pin.
1
PACTL IP
PACTL Input. When the PACTL pin is configured to be a GPIO, the state of this bit reflects the voltage on the PACTL pin.
For LPstar ,this bit is RSVD.
0
IRQ IP
IRQ Input. When the IRQ pin is configured to be a GPIO, the state of this bit reflects the voltage on
the IRQ pin
122
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x0Fh
10.5.16
XACT_CFG_ADR
Register
Individual Register Names and Addresses:
XACT_CFG_ADR :
0x0Fh
Access : POR
Bit Name
7
6
R/W:1
R/W:x
ACK EN
5
4
3
2
1
0
R/W:0
R/W:0
R/W:0
FRC END
END STATE
ACK TO
Bit
Name
Description
7
ACK EN
Acknowledge Enable. When this bit is set, an ACK packet is automatically transmitted whenever a
valid packet is received; in this case the device is considered to be in transaction mode. After transmission of the ACK packet, the device automatically transitions to the END STATE. When this bit is
cleared, the device transitions directly to the END STATE immediately after the end of packet transmission. This bit affects both transmitting and receiving devices.
5
FRC END
Force End State. Setting this bit forces a transition to the state set in END STATE. By setting the
desired END STATE at the same time as setting this bit the device may be forced to immediately
transition from its current state to any other state. This bit is automatically cleared upon completion.
Firmware MUST never try to force END STATE while TX GO is set, nor when RX GO is set and a
SOP has already been received (packet reception already in progress).
4:2
END STATE
Transaction End State. This field defines the mode to which the device transitions after receiving or
transmitting a packet.
000 = Sleep Mode
001 = Idle Mode
010 = Synth Mode (TX)
011 = Synth Mode (RX)
100 = RX Mode
In normal use, this field is typically set to 000 or 001 when the device is transmitting packets, and 100
when the device is receiving packets. Note that when the device transitions to receive mode as an
END STATE, the receiver must still be armed by setting RX GO before the device can begin receiving
data. If the system only support packets <=16 bytes then firmware should examine RXC IRQ and
RXE IRQ to determine the status of the packet. If the system supports packets > 16 bytes ensure that
END STATE is not sleep, force RXF=1, perform receive operation, force RXF=0, and if necessary set
END STATE back to sleep.
1:0
ACK TO
ACK Timeout. When the device is configured for transaction mode, this field sets the timeout period
after transmission of a packet during which an ACK must be correctly received in order to prevent a
transmit error condition from being detected. This timeout period is expressed in terms of a number of
SOP_CODE_ADR code lengths; if SOP LEN is set, then the timeout period is this value multiplied by
64 s and if SOP LEN is cleared then the timeout is this value multiplied by 32 s.
00 = 4x
01 = 8x
10 = 12x
11 = 15x the SOP_CODE_ADR code length
ACK_TO must be set to greater than 30 + Data Code Length (only for 8DR) + Preamble Length +
SOP Code Length (x2).
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
123
0x10h
10.5.17
FRAMING_CFG_ADR
Register
Individual Register Names and Addresses:
FRAMING_CFG_ADR : 0x10h
7
6
5
4
3
2
1
0
R/W:1
R/W:0
R/W:1
R/W:0
R/W:0
R/W:1
R/W:0
R/W:1
SOP EN
SOP LEN
LEN EN
Access : POR
Bit Name
SOP TH
Bit
Name
Description
7
SOP EN
SOP Enable. When this bit is set, each transmitted packet begins with a SOP field, and only packets
beginning with a valid SOP field are received. If this bit is cleared, no SOP field is generated when a
packet is transmitted, and packet reception begins whenever two successive correlations against the
DATA_CODE_ADR code are detected.
6
SOP LEN
SOP PN Code Length. When this bit is set the SOP_CODE_ADR code length is 64 chips. When this
bit is cleared the SOP_CODE_ADR code length is 32 chips.
5
LEN EN
Packet Length Enable. When this bit is set the 8-bit value contained in TX_LENGTH_ADR is transmitted immediately after the SOP field. In receive mode, the 8 bits immediately following the SOP
field are interpreted as the length of the packet. When this bit is cleared no packet length field is
transmitted. 8DR always sends the packet length field (forces LEN EN =1). GFSK requires user set
LEN EN = 1.
4:0
SOP TH
SOP Correlator Threshold. This is the receive data correlator threshold used when attempting to
detect a SOP symbol. There is a threshold for the SOP_CODE_ADR code. This (single) threshold is
applied independently to each of SOP1 and SOP2 fields. There are then two thresholds for each of
the 64-chip DATA_CODE_ADR codes and 32-chip DATA_CODE_ADR codes. When SOP LEN is
set, all 5 bits of this field are used. When SOP LEN is cleared, the most significant bit is disregarded.
Typical applications configure SOP TH = 04h for SOP32 and SOP TH = 0Eh for SOP64.
124
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x11h
10.5.18
DATA32_THOLD_ADR
Register
Individual Register Names and Addresses:
DATA32_THOLD_ADR : 0x11h
7
Access : POR
6
5
R/W:x
4
3
2
R/W:0
R/W:1
Bit Name
1
0
R/W:0
R/W:0
TH32
Bit
Name
Description
3:0:
TH32
32-Chip Data PN Code Correlator Threshold. This register sets the correlator threshold used in
DSSS modes when DATA CODE LENGTH (see “TX_CFG_ADR” on page 109) is set to 32. Typical
applications configure TH32 = 03h.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
125
0x12h
10.5.19
DATA64_THOLD_ADR
Register
Individual Register Names and Addresses:
DATA64_THOLD_ADR
7
Access : POR
0x12h
6
5
R/W:x
Bit Name
4
3
2
1
0
R/W:0
R/W:1
R/W:0
R/W:1
R/W:0
TH64
Bit
Name
Description
4:0
TH64
64-Chip Data PN Code Correlator Threshold. This register sets the correlator threshold used in
DSSS modes when the DATA CODE LENGTH (see “TX_CFG_ADR” on page 109) is set to 64. Typical applications configure TH64 = 07h.
126
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x13h
10.5.20
RSSI_ADR
Register
Individual Register Names and Addresses:
RSSI_ADR :
Access : POR
Bit Name
0x13h
7
6
5
R/W:0
R/W:x
R/W:1
R/W:0
LNA
RSSI
SOP
4
3
2
1
0
A Received Signal Strength Indicator (RSSI) reading is taken automatically when an SOP symbol is detected. In addition, an
RSSI reading is taken whenever RSSI_ADR is read. The contents of this register are not valid after the device is configured
for receive mode until either a SOP symbol is detected, or the register is read. The conversion can occur as often as once
every 12 µs. The approximate slope of the curve is 1.9 dB/count, but is not guaranteed.
If it is desired to measure the background RF signal strength on a channel before a packet has been received then the MCU
should perform a ‘dummy’ read of this register, the results of which should be discarded. This ‘dummy’ read causes an RSSI
measurement to be taken, and therefore subsequent readings of the register yield valid data.
Bit
Name
Description
7
SOP
SOP RSSI Reading. When set, this bit indicates that the reading in the RSSI field was taken when a
SOP symbol was detected. When cleared, this bit indicates that the reading stored in the RSSI field
was triggered by a previous SPI read of this register.
5
LNA
LNA State. This bit indicates the LNA state when the RSSI reading was taken. When cleared, this bit
indicates that the LNA was disabled when the RSSI reading was taken; if set this bit indicates that the
LNA was enabled when the RSSI reading was taken.
4:0
RSSI
RSSI Reading. This field indicates the instantaneous strength of the RF signal being received at the
time that the RSSI reading was taken. A larger value indicates a stronger signal. The signal strength
measured is for the RF signal on the configured channel, and is measured after the LNA stage.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
127
0x14h
10.5.21
EOP_CTRL_ADR
Register
Individual Register Names and Addresses:
EOP_CTRL_ADR :
Access : POR
Bit Name
0x14h
7
6
5
4
3
2
1
0
R/W:1
R/W:0
R/W:1
R/W:0
R/W:0
R/W:1
R/W:0
R/W:0
HEN
HINT
EOP
If the LEN EN bit is set, then the contents of this register has no effect. If the LEN EN bit is cleared, then this register is used
to configure how an EOP (end of packet) condition is detected.
Bit
Name
Description
7
HEN
EOP Hint Enable. When set, this bit causes an EOP to be detected if no correlations have been
detected for the number of symbol periods set by the HINT field and the last two received bytes
match the calculated CRC16 for all previously received bytes. Use of this mode reduces the chance
of non-correlations in the middle of a packet from being detected as an EOP condition.
6:4
HINT
EOP Hint Symbol Count. Hint is the minimum number of consecutive non-correlations symbols at
which the last two bytes are checked against the calculated CRC16 to detect an EOP condition. This
value cannot be ‘0’, i.e., these bits cannot be ‘000’.
3:0
EOP
EOP Symbol Count. An EOP condition is deemed to exist when the number of consecutive non-correlations is detected
128
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x15h
10.5.22
CRC_SEED_LSB_ADR
Register
Individual Register Names and Addresses:
CRC_SEED_LSB_ADR : 0x15h
7
6
Access : POR
5
4
3
2
1
0
R/W:0
Bit Name
CRC SEED LSB
The CRC16 seed allows different devices to generate or recognize different CRC16s for the same payload data. If a transmitter and receiver use a randomly selected CRC16 seed, the probability of correctly receiving data intended for a different
receiver is 1/65535, even if the other transmitter/receiver are using the same SOP_CODE_ADR codes and channel.
Bit
Name
Description
7:0
CRC SEED LSB
CRC16 Seed Least Significant Byte. The LSB of the starting value of the CRC16 calculation
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
129
0x16h
10.5.23
CRC_SEED_MSB_ADR
Register
Individual Register Names and Addresses:
CRC_SEED_MSB_ADR : 0x16h
7
6
5
Access : POR
4
3
2
1
0
R/W:0
Bit Name
CRC SEED MSB
Bit
Name
Description
7:0
CRC SEED MSB
CRC16 Seed Most Significant Byte. The MSB of the starting value of the CRC16 calculation.
130
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x17h
10.5.24
TX_CRC_LSB_ADR
Register
Individual Register Names and Addresses:
TX_CRC_LSB_ADR :
0x17h
7
6
Access : POR
5
4
3
2
1
0
R/W:x
Bit Name
TX CRC LSB
Bit
Name
Description
7:0
TX CRC LSB
Calculated CRC16 LSB. The LSB of the CRC16 that was calculated for the last transmitted packet.
This value is only valid after packet transmission is complete.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
131
0x18h
10.5.25
TX_CRC_MSB_ADR
Register
Individual Register Names and Addresses:
TX_CRC_MSB_ADR :
0x18h
7
6
5
Access : POR
4
3
2
1
0
R/W:x
Bit Name
TX CRC MSB
Bit
Name
Description
7:0
TX CRC MSB
Calculated CRC16 MSB. The MSB of the CRC16 that was calculated for the last transmitted packet.
This value is only valid after packet transmission is complete.
132
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x19h
10.5.26
RX_CRC_LSB_ADR
Register
Individual Register Names and Addresses:
RX_CRC_LSB_ADR : 0x19h
7
6
Access : POR
5
4
3
2
1
0
R/W:1
Bit Name
RX CRC LSB
Bit
Name
Description
7:0
RX CRC LSB
Received CRC16 LSB. The LSB of the CRC16 field from the last received packet. This value is valid
whether or not the CRC16 field matched the calculated CRC16 of the received packet.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
133
0x1Ah
10.5.27
RX_CRC_MSB_ADR
Register
Individual Register Names and Addresses:
RX_CRC_MSB_ADR: 0x1Ah
7
6
5
Access : POR
4
3
2
1
0
R/W:1
Bit Name
RX CRC MSB
Bit
Name
Description
7:0
RX CRC MSB
Received CRC16 MSB. The MSB of the CRC16 field from the last received packet. This value is valid
whether or not the CRC16 field matched the calculated CRC16 of the received packet.
134
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x1Bh
10.5.28
TX_OFFSET_LSB_ADR
Register
Individual Register Names and Addresses:
TX_OFFSET_LSB_ADR: 0x1Bh
7
6
Access : POR
5
4
3
2
1
0
R/W:0
Bit Name
STRIM LSB
Bit
Name
Description
7:0
STRIM LSB
The least significant 8 bits of the synthesizer offset value. This is a 12-bit 2’s complement signed
number which may be used to offset the transmit frequency of the device by up to ±1.5 MHz. A positive value increases the transmit frequency, and a negative value reduces the transmit frequency. A
value of +1 increases the transmit frequency by 732.6 Hz; a value of –1 decreases the transmit frequency by 732.6 Hz. A value of 0x0555 increases the transmit frequency by 1 MHz; a value of 0xAAB
decreases the transmit frequency by 1 MHz. Typically, this register is loaded with 0x55 during initialization. Typically this feature is used to avoid the need to change the synthesizer frequency when
switching between TX and RX. As the IF = 1 MHz the RX frequency is offset 1 MHz from the synthesizer frequency; therefore, transmitting with a 1 MHz offset allows the same synthesizer frequency to
be used for both transmit and receive.
Synthesizer offset has no effect on receive frequency.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
135
0x1Ch
10.5.29
TX_OFFSET_MSB_ADR
Register
Individual Register Names and Addresses:
TX_OFFSET_MSB_ADR :
7
Access : POR
0x1Ch
6
5
R/W:x
Bit Name
4
3
2
1
0
R/W:0
STRIM MSB
Bit
Name
Description
3:0
STRIM MSB
The most significant 4 bits of the synthesizer trim value. Typically, this register is loaded with 0x05
during initialization.
136
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x1Dh
10.5.30
MODE_OVERRIDE_ADR
Register
Individual Register Names and Addresses:
MODE_OVERRIDE_ADR :
7
0x1Dh
6
5
4
R/W:0
Access : POR
R/W:0
R/W:0
R/W:0
Bit Name
RSVD
RSVD
FRC SEN
3
R/W:0
2
1
R/W:x
FRC AWAKE
0
R/W:0
RST
Bit
Name
Description
7:6
RSVD
Reserved. Must be zero.
5
FRC SEN
Manually Initiate Synthesizer. Setting this bit forces the synthesizer to start. Clearing this bit has no
effect. For this bit to operate correctly, the oscillator must be running before this bit is set.
4:3
FRC AWAKE
Force Awake. Force the device out of sleep mode. Setting both bits of this field forces the oscillator to
keep running at all times regardless of the END STATE setting. Clearing both of these bits disables
this function.
0
RST
Reset. Setting this bit forces a full reset of the device. Clearing this bit has no effect.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
137
0x1Eh
10.5.31
RX_OVERRIDE_ADR
Register
Individual Register Names and Addresses:
RX_OVERRIDE_ADR :
7
6
5
4
3
2
1
0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:x
ACK RX
RXTX DLY
MAN RXACK
FRC RXDR
DIS CRC0
DIS RXCRC
ACE
Access : POR
Bit Name
0x1Eh
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7
ACK RX
When this bit is set, the device uses the transmit synthesizer frequency rather than the receive synthesizer frequency for the given channel when automatically entering receive mode.
6
RXTX DLY
When this bit is set and ACK EN is enabled, the transmission of the ACK packet is delayed by 20 s.
5
MAN RXACK
Force Expected Packet Type. When this bit is set, and the device is in receive mode, the device is
configured to receive an ACK packet at the data rate defined in TX_CFG_ADR.
4
FRC RXDR
Force Receive Data Rate. When this bit is set, the receiver ignores the data rate encoded in the SOP
symbol, and receives data at the data rate defined in TX_CFG_ADR.
3
DIS CRC0
Reject packets with a zero-seed CRC16. Setting this bit causes the receiver to reject packets with a
zero-seed, and accept only packets with a CRC16 that matches the seed in CRC_SEED_LSB_ADR
and CRC_SEED_MSB_ADR.
2
DIS RXCRC
The RX CRC16 checker is disabled. If packets with CRC16 enabled are received, the CRC16 is
treated as payload data and stored in the receive buffer.
1
ACE
Accept Bad CRC16. Setting this bit causes the receiver to accept packets with a CRC16 that do not
match the seed in CRC_SEED_LSB_ADR and CRC_SEED_MSB_ADR. An ACK is to be sent
regardless of the condition of the received CRC16
138
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x1Fh
10.5.32
TX_OVERRIDE_ADR
Register
Individual Register Names and Addresses:
TX_OVERRIDE_ADR : 0x1Fh
7
Access : POR
Bit Name
6
5
4
3
2
1
0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
ACK TX
FRC PRE
RSVD
MAN TXACK
OVRD ACK
DIS TXCRC
RSVD
TX INV
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7
ACK TX
When this bit is set, the device uses the receive synthesizer frequency rather than the transmit synthesizer frequency for the given channel when automatically entering transmit mode.
6
FRC PRE
Force Preamble. When this bit is set, the device transmits a continuous repetition of the preamble
pattern (see “PREAMBLE_ADR” on page 152) after TX GO is set. This mode is useful for some regulatory approval procedures. Firmware must set bit RST of MODE_OVERRIDE_ADR to exit this
mode.
5
RSVD
Reserved. Must be zero.
4
MAN TXACK
Transmit ACK Packet. When this bit is set, the device sends an ACK packet when TX GO is set.
3
OVRD ACK
ACK Override. Use TX_CFG_ADR to determine the data rate and the CRC16 used when transmitting
an ACK packet.
2
DIS TXCRC
Disable Transmit CRC16. When set, no CRC16 field is present at the end of transmitted packets.
1
RSVD
Reserved. Must be zero.
0
TX INV
TX Data Invert. When this bit is set the transmit bit stream is inverted.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
139
0x26h
10.5.33
XTAL_CFG_ADR
Register
Individual Register Names and Addresses:
XTAL_CFG_ADR :
Access : POR
Bit Name
0x26h
7
6
5
4
3
2
1
0
W:0
W:0
W:0
W:0
W:0
W:0
W:0
W:0
RSVD
RSVD
RSVD
RSVD
START DLY
RSVD
RSVD
RSVD
This register provides the ability to override some automatic features of the device.
Bit
Name
Description
7:4
RSVD
Reserved. Must be zero.
3
START DLY
Crystal Startup Delay. Setting this bit sets the crystal startup delay to 150 ms to handle warm restarts
of the crystal. Firmware MUST set this bit during initialization.
2:0
RSVD
Reserved. Must be zero.
140
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x27h
10.5.34
CLK_OFFSET_ADR
Register
Individual Register Names and Addresses:
CLK_OFFSET_ADR :
0x27h
7
6
5
4
3
2
1
0
Access : POR
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
Bit Name
RSVD
RSVD
RSVD
RSVD
RSVD
RSVD
RXF
RSVD
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7:2
RSVD
Reserved. Must be zero.
1
RXF
Force Receive Clock. Streaming applications MUST set this bit during receive mode, otherwise this
bit should be cleared.
0
RSVD
Reserved. Must be zero.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
141
0x28h
10.5.35
CLK_EN_ADR
Register
Individual Register Names and Addresses:
CLK_EN_ADR :
0x28h
7
6
5
4
3
2
1
0
Access : POR
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
Bit Name
RSVD
RSVD
RSVD
RSVD
RSVD
RSVD
RXF
RSVD
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7:2
RSVD
Reserved. Must be zero.
1
RXF
Force Receive Clock Enable. Streaming applications MUST set this bit during initialization.
0
RSVD
Reserved. Must be zero.
142
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x29h
10.5.36
RX_ABORT_ADR
Register
Individual Register Names and Addresses:
RX_ABORT_ADR :
0x29h
7
6
5
4
3
2
1
0
Access : POR
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
Bit Name
RSVD
RSVD
ABORT EN
RSVD
RSVD
RSVD
RSVD
RSVD
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7:6
RSVD
Reserved. Must be zero.
5
ABORT EN
Receive Abort Enable. Typical applications disrupt any pending receive by first setting this bit, otherwise this bit is cleared.
4:0
RSVD
Reserved. Must be zero.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
143
0x32h
10.5.37
AUTO_CAL_TIME_ADR
Register
Individual Register Names and Addresses:
AUTO_CAL_TIME_ADR 0x32h
7
6
5
Access : POR
4
3
2
1
0
R/W:0
Bit Name
AUTO_CAL_TIME
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7:0
AUTO_CAL_TIME
Auto Cal Time. Firmware MUST write 3Ch to this register during initialization.
144
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x35h
10.5.38
AUTO_CAL_OFFSET_ADR
Register
Individual Register Names and Addresses:
AUTO_CAL_OFFSET_ADR : 0x35h
7
6
5
Access : POR
4
3
2
1
0
R/W:0
Bit Name
AUTO_CAL_OFFSET
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
7:0
AUTO_CAL_OFFSET
Description
Auto Cal Offset. Firmware MUST write 14h to this register during initialization.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
145
0x39h
10.5.39
ANALOG_CTRL_ADR
Register
Individual Register Names and Addresses:
ANALOG_CTRL_ADR : 0x39h
7
6
5
4
3
2
1
0
Access : POR
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
R/W:0
Bit Name
RSVD
RSVD
RSVD
RSVD
RSVD
RSVD
RX INV
ALL SLOW
This register provides the ability to over-ride some automatic features of the device.
Bit
Name
Description
7:2
RSVD
Reserved. Must be zero.
1
RX INV
0
ALL SLOW
When set, the incoming receive data is inverted. Firmware MUST set this bit when interoperability
with first generation devices is desired.
All Slow. When set, the synth settling time for all channels is the same as for slow channels. It is recommended that firmware set this bit when using GFSK data rate mode. This bit must be set to communicate in DDR/SDR mode for legacy mode communication.
146
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x20h
10.5.40
TX_BUFFER_ADR
Byte Register File
Individual Register Names and Addresses:
TX_BUFFER_ADR : 0x20h
Access : POR
7
6
5
4
3
2
1
0
W:x
W:x
W:x
W:x
W:x
W:x
W:x
W:x
Byte Name
Access : POR
15
14
13
12
11
10
9
8
W:x
W:x
W:x
W:x
W:x
W:x
W:x
W:x
Byte Name
The transmit buffer is a FIFO. Writing to this file adds a byte to the packet being sent. Writing more bytes to this file than the
packet length in TX_LENGTH_ADR has no effect, and these bytes are lost. The FIFO accumulates data until it is reset via TX
CLR in TX_CTRL_ADR. A previously sent packet of 16 bytes or less, can be transmitted if TX_GO is set without resetting the
FIFO. The contents of TX_BUFFER_ADR are not affected by the transmission of an Auto ACK packet.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
147
0x21h
10.5.41
RX_BUFFER_ADR
Byte Register File
Individual Register Names and Addresses:
RX_BUFFER_ADR : 0x21h
Access : POR
7
6
5
4
3
2
1
0
R:x
R:x
R:x
R:x
R:x
R:x
R:x
R:x
15
14
13
12
11
10
9
8
R:x
R:x
R:x
R:x
R:x
R:x
R:x
R:x
Byte Name
Access : POR
Byte Name
The receive buffer is a FIFO. Received bytes may be read from this file register at any time that it is not empty, but when reading from this file register before a packet has been completely received care must be taken to ensure that error packets (for
example with bad CRC16) are handled correctly.
When the receive buffer is configured to be overwritten by new packets (the alternative is for new packets to be discarded if
the receive buffer is not empty), similar care must be taken to verify after the packet has been read from the buffer that no part
of it was overwritten by a newly received packet while this file register is being read.
When the VLD EN bit in RX_CFG_ADR is set, the bytes in this file register alternate—the first byte read is data, the second
byte is a valid flags for each bit in the first byte, the third byte is data, the fourth byte valid flags, and so on. In SDR and DDR
modes the valid flag for a bit is set if the correlation coefficient for the bit exceeded the correlator threshold, and is cleared if it
did not. In 8DR mode, the MSB of a valid flags byte indicates whether or not the correlation coefficient of the corresponding
received symbol exceeded the threshold. The seven LSB’s contain the number of erroneous chips received for the data.
148
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x22h
10.5.42
SOP_CODE_ADR
Byte Register File
Individual Register Names and Addresses:
SOP_CODE_ADR :
Access : POR
0x22h
7
6
5
4
3
2
1
0
R/W:
R/W:
R/W:
R/W:
R/W:
R/W:
R/W:
R/W:
Bit Name
When using 32-chip SOP_CODE_ADR codes, only the first four bytes of this register are used; in order to complete the file
write process, these four bytes must be followed by four bytes of ‘dummy’ data. However, a class of codes known as ‘multiplicative codes’ may be used; there are 64-chip codes with good auto-correlation and cross-correlation properties where the
least significant 32 chips themselves have good auto-correlation and cross-correlation properties when used as 32-chip
codes. In this case the same eight-byte value may be loaded into this file and used for both 32-chip and 64-chip SOP symbols.
When reading this file, all eight bytes must be read; if fewer than eight bytes are read from the file, the contents of the file are
rotated by the number of bytes read. This applies to writes, as well.
Recommended SOP Codes:
0x91CCF8E291CC373C
0x0FA239AD0FA1C59B
0x2AB18FD22AB064EF
0x507C26DD507CCD66
0x44F616AD44F6E15C
0x46AE31B646AECC5A
0x3CDC829E3CDC78A1
0x7418656F74198EB9
0x49C1DF6249C0B1DF
0x72141A7F7214E597
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
149
0x23h
10.5.43
DATA_CODE_ADR
Byte Register File
Individual Register Names and Addresses:
DATA_CODE_ADR : 0x23h
Access : POR
7
6
5
4
3
2
1
0
R/W:x
R/W:x
R/W:x
R/W:x
R/W:x
R/W:x
R/W:x
R/W:x
15
14
13
12
11
10
9
8
R/W:x
R/W:x
R/W:x
R/W:x
R/W:x
R/W:x
R/Wx:
R/W:x
Bit Name
Access : POR
Bit Name
In GFSK mode, this file register is ignored.
In 64-SDR mode, only the first eight bytes are used.
In 32-DDR mode, only eight bytes are used. The format for these eight bytes is the following:
0x0000 0000 BBBB BBBB 0000 0000 AAAA AAAA,
where ‘0’ represents unused locations.
Example: 0x00000000B2BB092B00000000B86BC0DC;
where ‘B86BC0DC’ represents AAAAAAAA, ‘0000000’ represents unused locations, ‘B2BB092B’ represents BBBBBBBB,
and ‘00000000’ represents unused locations.
In 64-DDR and 8DR modes, all sixteen bytes are used.
When reading this file, all sixteen bytes must be read; if fewer than sixteen bytes are read from the file, the contents of the file
are rotated by the number of bytes read. This applies to writes, as well.
Certain sixteen-byte sequences have been calculated that provide excellent auto-correlation and cross-correlation properties,
and it is recommended that such sequences be used; the default value of this register is one such sequence. In typical applications, all devices use the same DATA_CODE_ADR codes, and devices and systems are addressed by using different
SOP_CODE_ADR codes; in such cases it may never be necessary to change the contents of this register from the default
value.
Typical applications should use the default code.
150
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
0x24h
10.5.44
PREAMBLE_ADR
Byte Register File
Individual Register Names and Addresses:
PREAMBLE_ADR :
0x24h
7
6
Access : POR
5
4
3
2
1
0
R/W:x
R/W:x
R/W:x
Bit Name
This register is three bytes in length.
Byte
3
2
1
Name
Description
Most significant eight chips of the preamble sequence.
Least significant eight chips of the preamble sequence.
The number of repetitions of the preamble sequence that are to be transmitted. The preamble may be
disabled by writing 0x00 to this byte.
If using 64-SDR to communicate with CYWUSB69xx devices, set number of repetitions to eight for optimum performance.
If using DDR/32 -DDR to communicate with CYWUSB69xx devices, set number of repetitions to four for optimum performance.
When reading this file, all three bytes must be read; if fewer than three bytes are read from the file, the contents of the file are rotated by the
number of bytes read. This applies to writes, as well.
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
151
0x25h
10.5.45
MFG_ID_ADR
Byte Register File
Individual Register Names and Addresses:
MFG_ID_ADR :
0x25h
7
Access : POR
6
5
4
3
2
1
0
R:x
R:x
R:x
R:x
R:x
R:x
Bit Name
This register is six bytes long.
To minimize ~190 µA of current consumption (default), execute a ‘dummy’ single-byte SPI write to this address with a zero
data stage after the contents have been read. Non-zero to enable reading of fuses. Zero to disable reading fuses.
152
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Index
A
abbreviations 9
ACK 17, 66, 101, 102, 123
auto 66
timeout 123
acronyms 11
AGC
See automatic gain control
ALL SLOW 60
ANALOG_CTRL_ADR 60, 146
antenna
performance 29
application note, associated 9
ATS
See automatic transaction sequencer
ATT 113
See receive attenuator
attenuation 14
auto ACK 17
auto transaction sequencer 17, 26
AUTO_CAL_OFFSET_ADR 145
AUTO_CAL_TIME_ADR 144
automatic gain control 113
B
backward compatbility 61
baseband 59
battery 24
binding 28
button 29
factory 29
manual 29
manufacturing 29
power up 29
bit error rate 25, 30, 99
buffer
receive 17, 94, 95, 113, 148
transmit 17, 94, 95, 108, 147
C
capacitors 54
channel 15, 71, 72
changing 28
co-location 28
fast 102
fast changes 17, 113
medium 102
quiet 28
selection 28
slow 102, 146
synthesizer settle 17
CHANNEL_ADR 102, 106
chip 25, 27, 60, 66
center 60
centering 64
rate 60
CLK_EN_ADR 142
CLK_OFFSET_ADR 141
clock 59
collissions
packet 27
co-location 28, 64
bandwidth 28
throughput 28
configuration 67
transmit 73
conventions
registers 104
correlate 63
correlator 60, 64
cost 29
CRC_SEED_LSB_ADR 65, 80, 129
CRC_SEED_MSB_ADR 65, 80, 130
crystal
accuracy 47
aging 48
equivalent series resistance 102
frequency 47
layout 48
load capacitance 48
PPM 65, 107
ppm 47, 48
pullability 48
requirements 47
schematic 49
selection 48
stabilization 102
startup 17
temperature 48
trim sensitivity 48
current
average 24
measuring 102
peak 24
sleep current 17
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
153
Index
CY3631 Manufacturing Test Kit 30
cyclic redundancy check 15, 16, 17, 26, 59, 63, 65,
66, 107
co-location 28
disable 138
error 116, 138
result
receive 133, 134
transmit 131, 132
seed 129, 130
zero seed 116
D
DATA CODE LENGTH 60
DATA MODE 60
data mode 60, 67, 116
8DR 25, 60, 63, 65, 116
DDR 25, 60, 61, 65
GFSK 60, 61, 63, 64, 65, 116
SDR 25, 60, 61
data rate 25, 60, 63, 108
dynamic 60, 63
latency 26
mixed mode 60, 63
data rmode
DDR 116
data sheets to reference 9
DATA_CODE_ADR 60, 61, 82, 124, 150
DATA32_THOLD_ADR 76
DATA64_THOLD_ADR 77, 126
diode 54
direct sequence spread spectrum 13, 17, 25, 27,
60, 65, 99
direction
master/slave 27
transmitter/receiver 27
DIS TXCRC 65
document
abbreviations and acronyms 11
document history 10
driver 82
FRAMING_CFG_ADR 75
initialization 67
RadioAbort 85
RadioBlockingTransmit 86
RadioBurstRead 96
RadioBurstWrite 95
RadioEndReceive 89
RadioEndTransmit 84
RadioFileRead 97
RadioFileWrite 96
RadioGetChannel 72
RadioGetCrcSeed 80
RadioGetFrameConfig 75
RadioGetFrequency 72
RadioGetFuses 81
RadioGetPreambleCount 78
RadioGetPreamblePattern 79
RadioGetReceiveState 88, 92
RadioGetReceiveStatus 89
154
RadioGetRssi 81
RadioGetThreshold32 76
RadioGetThreshold64 77
RadioGetTransmitState 84, 92
RadioGetTxConfig 73
RadioGetXactConfig 74
RadioInit 70
RadioInterrupt 90
RadioPoll 91
RadioRead 93
RadioReset 93
RadioSetChannel 71
RadioSetConstSopPnCode 82
RadioSetCrcSeed 80
RadioSetFrameConfig 75
RadioSetFrequency 71
RadioSetLength 95
RadioSetPreambleCount 78
RadioSetPreamblePattern 79
RadioSetPtr 94
RadioSetSopPnCode 83
RadioSetThreshold32 76
RadioSetThreshold64 77
RadioSetTxConfig 73
RadioSetXactConfig 74
RadioStartReceive 87
RadioStartTransmit 83
RadioWrite 94
receive 68
transmit
blocking 68
non-bocking 68
DSSS
See direct sequence spread spectrum
E
enCoRe II 67
end of packet 59, 66
end state 67
awake 137
force 123, 137
synthesizer settle 137
EOP 66
EOP_CTRL_ADR 66, 128
error 112
correction 26, 99
detection 26
receive 112, 115, 116
transmit 111
F
field
DATA CODE LENGTH 60
DATA MODE 60
DIS TXCRC 65
EOP 66
HEN 66
HINT 66
LEN EN 65
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Index
SOP EN 64
SOP LEN 64
FIFO
receive 17, 26, 94, 95, 113, 148
transmit 17, 26, 94, 95, 108, 147
footprint 29
framer 59, 60, 63, 65
framing 17, 60
FRAMING_CFG_ADR 64, 65, 75, 124
frequency 71, 72
fuses 152
G
gausian frequency shift key
See GFSK
GFSK 25, 28
GPIO_CTRL_ADR 122
H
hard reset 34
HEN 66
HILO 113
HINT 66
I
idle
mode 123
inductor 54
Initialization 70
initialization 67
interference 14
avoidance 27
detection 28
overcoming 28
rejection 99
interrupt 90
low voltage 110, 119
oscillator stable 110, 120
receive 112, 115
receive buffer 112, 114
receive error 115
transmit buffer 108, 110
transmit complete 110
IO_CFG_ADR 121
IRQ 68, 90, 121, 122
L
latency 26, 100, 101
layout
crystal 48
LEN EN 65
length 15, 16, 59, 60, 65, 66, 107, 117, 118, 124
end of packet 66
maximum 107
LNA
See low noise amplifier
low noise amplifier 113, 127
low voltage indicator 17
M
M8C 19, 67
manufacturability 29
measurement units 11
MFG_ID_ADR 81, 152
microcontroller
M8C 19
MISO 121, 122
mode
idle 100, 123
receive 102, 123
receivr 100
sleep 100, 123
synthesizer settle 100
transmit 100, 102
transmit synthesizer settle 123
MODE_OVERRIDE_ADR 137, 139
modem 59, 60, 63, 64
multi-path 14
N
network
mesh 26
star 26
topology 26
P
PA
See power amplifier
package
CYRF6936 17
packet 63
collisions 27
direction 27
framing 17
frequency 25, 100
length 107, 117, 118, 124
maximum 107
recovery 27
rejection 27
size 25, 100
type 28
packet error rate 30, 99
packet length 15, 16
PACTL 121, 122
payload
frequency 25
size 25
phase locked loop 71
pin
IRQ 68, 90, 121, 122
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
155
Index
MISO 121, 122
PACTL 121, 122
RST 50
SS 68
Vbat 50
XOUT 48, 50, 120, 121, 122
XTAL 50
PMU
See power management unit
PMU EN 51
PN code 16, 25, 60
co-location 28, 64
data 60, 61, 63, 64, 109, 150
data threshold 125, 126
SOP 108, 149
threshold
data 27
SOP 27
POR
See power on reset
via capacitor 31
via microcontroller 33
power 23
battery 99
battery powered 24
constraints 27
consumption 23
measuring 102
minimize 26
receive 102
sleep 99
supply 23
Vbat 50
transmit 102
transmit power 17
power amplifier 24, 28, 109
power cycle POR 35
power management unit 17, 59
enable 119
output voltage 119
sleep 119
power on reset 31
PPM 107
preamble 63, 66, 102, 108
force 139
length 63
pattern 63
PREAMBLE_ADR 63, 78, 79, 102, 151
protocol 15
pseudo noise codes 16
PSoC 67
PWR_CTRL_ADR 119
R
radio resets 31
RadioSetConstDataPnCode 82
range 24
receive 68, 112
abort 85, 143
156
end 89, 112, 115
error 112, 115, 116
mode 123
power 102
start 87
status 88, 89, 91, 92
receive attenuator 113
receive sensitivity 17, 24, 99
receive signal strength indication 17, 28
results 127
register
ANALOG_CTRL_ADR 60, 146
AUTO_CAL_OFFSET_ADR 145
AUTO_CAL_TIME_ADR 144
CHANNEL_ADR 102, 106
CLK_EN_ADR 142
CLK_OFFSET_ADR 141
conventions 104
CRC_SEED_LSB_ADR 65, 80, 129
CRC_SEED_MSB_ADR 65, 80, 130
DATA_CODE_ADR 60, 61, 82, 124, 150
DATA32_THOLD_ADR 76
DATA32_THOLD_ADRDATA32_THOLD_ADR 125
DATA64_THOLD_ADR 77, 126
EOP_CTRL_ADR 66, 128
file 96, 97, 147, 148, 149, 150, 151, 152
FRAMING_CFG_ADR 64, 65, 124
GPIO_CTRL_ADR 122
IO_CFG_ADR 121
MFG_ID_ADR 81, 152
MODE_OVERRIDE_ADR 137, 139
PREAMBLE_ADR 63, 78, 79, 102, 151
PWR_CTRL_ADR 119
RSSI_ADR 81, 127
RX_ABORT_ADR 143
RX_BUFFER_ADR 65, 148
RX_CFG_ADR 113
RX_COUNT_ADR 117
RX_CRC_LSB_ADR 65, 133
RX_CRC_MSB_ADR 65, 134
RX_IRQ_STATUS_ADR 114
RX_LENGTH_ADR 117, 118
RX_OVERRIDE_ADR 65, 138
RX_STATUS_ADR 116
SOP_CODE_ADR 64, 82, 83, 124, 149
TX_BUFFER_ADR 65, 101, 147
TX_CFG_ADR 60, 67, 70, 109
TX_CRC_LSB_ADR 65
TX_CRC_MSB_ADR 65, 132
TX_CTRL_ADR 101, 108
TX_IRQ_STATUS_ADR 110
TX_LENGTH_ADR 65, 107
TX_OFFSET_LSB_ADR 135
TX_OFFSET_MSB_ADR 136
TX_OVERRIDE_ADR 65, 139
XACT_CFG_ADR 50, 66, 67, 74, 123
XTAL_CTRL_ADR 48, 50, 120
register descriptions 105
register details and examples 106
reset 50, 93
hard 34
soft 35
software 137
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
Index
resets
radio 31
RSSI
See receive signal strength indication
RSSI_ADR 81, 127
RX_ABORT_ADR 143
RX_BUFFER_ADR 65, 148
RX_CFG_ADR 113
RX_COUNT_ADR 117
RX_CRC_LSB_ADR 65, 133
RX_CRC_MSB_ADR 65, 134
RX_IRQ_STATUS_ADR 114
RX_LENGTH_ADR 117, 118
RX_OVERRIDE_ADR 65, 138
RX_STATUS_ADR 116
S
schematic
crystal 49
serial peripheral interface 67, 68, 93
burst read 96
burst write 95
debug 102
file read 97
file write 96
MISO 121
read 93, 96, 97
sleep access 17
write 94, 95, 96
slave select 68
sleep 99
mode 123
power management unit 119
sleep current 17
soft reset 35
SOP 107, 124
PN code 108
See start of packet
SOP EN 64
SOP LEN 64
SOP_CODE_ADR 64, 82, 83, 124, 149
start of packet 59, 60, 63, 64, 66, 107, 124
60
PN code 63, 64
SOP 16
symbol 60, 61, 63, 66
start of packet 63, 64
synthesizer
channel change 17
fast changes 113
settling time 102
timing 146
synthesizer settle
mode 123
operating range 17
testing 29
electromagnetic interference (EMI) 30
electrostatic discharge (ESD) 30
electrostatic fast transient burst (EFTB) 30
manufacturing 30
quality assurance 29
regulatory
ETSI 30
FCC 30
TELEC 30
shielded chamber 30
throughput 25
time-to-market 29
timing 101
tranmsit
power 102
transmit 68
blocking 86
configuration 73
end 84, 110
error 111
start 83, 86, 108
status 84, 91, 92
transmit power 17
TX_BUFFER_ADR 65, 101, 147
TX_CFG_ADR 60, 67, 70, 109
TX_CRC_LSB_ADR 65
TX_CRC_MSB_ADR 65, 132
TX_CTRL_ADR 101, 108
TX_IRQ_STATUS_ADR 110
TX_LENGTH_ADR 65, 107
TX_OFFSET_LSB_ADR 135
TX_OFFSET_MSB_ADR 136
TX_OVERRIDE_ADR 65, 139
U
units of measure 11
V
Vbat 50
voltage
operating range 17, 19
range 24
X
XACT_CFG_ADR 66, 67, 74, 123
XOUT 48, 50, 120, 121, 122
XTAL 50
XTAL_CTRL_ADR 120
T
temperature
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J
157
Index
158
WirelessUSB™ LP/LPstar and PRoC™ LP/LPstar TRM, Document # 001-12603 Rev. *J